chaoxing-mcp

by OSSKn4w7

Overview Schema Source Related Servers Score Discussions Admin

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools have clearly scoped purposes, but cx_s_list_learning_courses and cx_list_courses overlap heavily for student course listing, and cx_s_download_material vs cx_s_download_attachment both perform objectId-based downloads from different sources. Descriptions help clarify the intended resource, but an agent could still misselect between these pairs.
Naming Consistency4/5
The set largely follows a verb_noun pattern with a consistent cx_s_ prefix for student operations and cx_ for auth/session operations. Minor inconsistencies exist: cx_session_status is noun-style, cx_s_list_learning_courses vs cx_list_courses use different names for similar listing actions, and material/materials singular/plural are mixed.
Tool Count4/5
16 tools is at the upper edge but still reasonable for a platform server covering auth, courses, chapters, materials, homework, exams, sign-in, and downloads. There is some redundancy that could be trimmed, but no tool feels entirely out of place.
Completeness4/5
The server covers the main student workflows: login/session management, course listing, content/material access, homework reading and submission, sign-in, and exam listing. The most notable gap is that exams are read-only with no submission workflow, but the core learning-assistant surface is otherwise coherent.
Average 3.7/5 across 16 of 16 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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 提供只读/副作用信息，描述仅说明‘下载到本地’，未披露文件保存行为、是否覆盖、错误处理、权限要求或返回内容等关键行为特征。
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?
描述用一句话完成了核心说明，没有冗余内容，信息集中在关键动作上，但略显过于简短。
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?
面对 2 个必填参数且 schema 无描述、无 annotations 的情况，描述只覆盖了部分语义，缺少 saveDir 和 objectId 的详细说明，也未提及输出行为，整体信息不足以支撑代理可靠调用。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema 描述覆盖率为 0%，描述中仅提到了 objectId 的定位作用，完全没有解释 saveDir 的含义、必需格式或与 objectId 的关系，无法帮助代理正确构造参数。
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?
描述明确说明了工具的作用：将作业/资料附件下载到本地，并指出定位方式为 objectId。虽然未与兄弟工具 cx_s_download_material 明确区分，但‘附件’这个措辞提供了一定区分度。
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?
没有提供任何使用场景说明，未说明何时应使用此工具而不是 cx_s_download_material 或其他下载类工具，也没有给出前置条件或注意事项。
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?
No annotations are provided, so the description carries the full burden. It implies a read-only 'view' operation and mentions that data is parsed from a menu page, but it does not disclose auth requirements, failure behavior, side effects, or whether a prior login/session is needed. The description adds only minimal behavioral context beyond the tool name.
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 a single compact sentence with no filler; the main purpose is front-loaded and the source detail is placed in parentheses. It is concise, though it could have used the brevity to add more parameter or usage context.
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 is simple (one required parameter, output schema present), but the definition still leaves the crucial input courseRef unexplained and gives no guidance about when to choose this tool over its many siblings. An agent cannot confidently construct a correct call without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the only parameter, courseRef, and the description never explains what values it expects or how it relates to the query. The property name 'courseRef' gives some hint, but the description does not compensate for the missing schema documentation.
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 a specific verb ('查看' / view) and resource ('课程学习记录' / course study records), and it adds the source page (menu '学习记录/统计'). It does not explicitly differentiate from sibling tools like cx_s_list_learning_courses, but the resource and name are specific enough to convey intent.
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?
There is no guidance about when to use this tool versus alternatives such as cx_s_list_learning_courses, nor any mention of prerequisites, exclusions, or expected context. The parenthetical about page parsing is an implementation note, not a usage guideline.
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?
No annotations are provided, so the description carries the full burden. It does add a useful behavioral detail—'getYunFiles 直链优先' (direct link preferred)—but it omits side effects like file creation/overwriting, authentication expectations, and failure behavior. Some transparency, but not comprehensive.
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 a single front-loaded sentence with no filler, and the parenthetical designates an important implementation preference. It is tight, though it could have used the saved space to clarify saveDir without becoming bloated.
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?
For a two-parameter tool with no annotations and zero parameter descriptions, this definition leaves significant gaps: saveDir behavior, objectId source/format, failure modes, and when to prefer this downloader over attachments. The existence of an output schema covers return values but not the missing input semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that objectId identifies the material to download, but saveDir is completely unexplained: its role, requirements, or path semantics are not stated. Only partial parameter coverage.
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 a specific verb ('下载' download), a resource ('课程资料' course materials), and the key identifier (objectId). It does not explicitly name or differentiate from sibling cx_s_download_attachment, but the 'course materials' phrasing and the getYunFiles direct-link note give some distinguishing context.
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?
There is no guidance about when to use this tool versus siblings such as cx_s_download_attachment, nor any preconditions, exclusions, or fallback behavior. The only implicit usage clue is 'download by objectId', which is not enough to resolve ambiguity.
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?
No annotations are provided, so the description carries the full burden. It indicates a read-only listing operation, but it does not disclose authentication needs, session requirements, or any other behavioral constraints.
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 front-loaded sentence with no filler. It states the action, the object, and the key content in a compact, easy-to-parse form.
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 one required parameter, no annotations, and no parameter documentation in either the schema or description, the definition is incomplete for reliable invocation. The output schema exists, but the agent still lacks essential input semantics and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not define courseRef, its format, or where to obtain it. The parameter name gives a small hint, but the description adds no real semantic value 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 states a specific action and resource: '列出课程章节树' (list course chapter tree), and clarifies the content as chapter names and links. This distinguishes it from sibling tools that operate on courses, homeworks, exams, or materials.
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?
There is no guidance about when to use this tool instead of a sibling, how to obtain courseRef, or whether it should follow cx_list_courses or cx_s_list_learning_courses. The intended context is only implied by the resource name.
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?
No annotations are provided, so the description is the main behavioral signal. It clearly indicates a read/list operation and the output fields, but it does not mention prerequisites like session/login, pagination, sorting, or whether results are scoped only to the supplied courseRef.
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 one compact sentence, front-loaded with the verb and resource, and the parenthetical field list adds useful detail without waste.
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?
Although the tool is simple and has an output schema, the description leaves important gaps: courseRef semantics are undocumented, and the relationship to sibling tools like cx_s_get_homework_detail is not addressed. This is insufficient for reliable tool selection without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain courseRef beyond the general word '课程'. The agent cannot tell whether courseRef is an ID, name, or other reference, how to obtain it, or what format to use.
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 uses a specific verb ('列出') and resource ('课程作业'), and enumerates the returned fields (标题/状态/时间/详情链接). This makes the tool's purpose clear, though it does not explicitly contrast it with the sibling cx_s_get_homework_detail.
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: an agent would use this when it needs a list of homework summaries for a course. However, the description gives no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as cx_s_get_homework_detail for individual homework details.
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?
With no annotations provided, the description carries the full burden and does well by explicitly stating '读取' (read) and '不会自动作答或提交' (will not auto-answer or submit), conveying a read-only, non-mutating behavior. It also discloses the response contents (questions, attachments, standardEnc), though it omits authentication prerequisites or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that states the action and enumerates the returned content, followed by a concise safety clarification. Every word earns its place without fluff.
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 purpose, content, and non-mutation, and an output schema exists to define return values. However, it does not explain how to obtain or supply workUrl and courseRef, nor does it explicitly guide selection among sibling tools, leaving moderate ambiguity for a two-parameter call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented workUrl and courseRef parameters, but it never mentions them or explains how they are used. The only weak inference is that one parameter identifies the homework, which is insufficient for correct invocation.
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 specifies a clear verb and resource: '读取作业详情' (read homework details), and enumerates exact content: question list (stem/options/type), attachment list, and standardEnc. It also differentiates from siblings by explicitly stating it will not auto-answer or submit, positioning it apart from cx_s_submit_homework.
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 you need a homework's question list, attachments, or standardEnc—but it does not explicitly state selection conditions or positive alternatives. The only contrast is the negative '不会自动作答或提交', which serves as a behavioral disclaimer rather than routing 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?
With no annotations provided, the description carries the full disclosure burden. It discloses that the operation is a read-only listing returning metadata (name/objectId), but does not address auth requirements, error behavior, or pagination. This is acceptable for a simple list operation but leaves some behavioral gaps.
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, front-loaded sentence with no filler. It conveys the operation, scope, and output in minimal 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 list tool with an output schema, the description covers the main operation and return shape. However, it omits guidance on the required courseRef parameter and any situational context, so an agent must infer how to populate the only argument.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not explain courseRef, such as whether it is a course ID, code, or reference object, or where to obtain it. The parameter name is self-descriptive at a high level, but the description adds no semantic detail 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 identifies a specific action ('列出' / list) and resource (the course '资料' / materials directory), and specifies the returned data (file name/objectId). This clearly distinguishes it from siblings like cx_s_download_material (download) and cx_s_list_chapters (chapter listing).
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 it should be used when the agent needs to enumerate files in a course's materials directory, which is clear context. However, it does not explicitly state when to prefer it over sibling list/download tools, nor mention prerequisites such as a valid courseRef.
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?
No annotations are provided, so the description must carry the full behavioral transparency burden. It only labels the sign-in modes and does not disclose side effects, such as recording attendance, authentication requirements, failure behavior, or whether sign-in can be repeated or reversed.
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 compact sentence with the action front-loaded and the mode list in parentheses. There is no filler, repetition, or unnecessary detail, making it easy for an agent to parse quickly.
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 seven parameters, zero schema description coverage, no annotations, and no enums, the description is too brief to fully support correct invocation. An agent would still need to infer conditional requirements, such as when code, latitude, longitude, or photoPath must be supplied for each mode.
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?
Schema coverage is 0%, so the description is the main source of parameter meaning. It helps by mapping the signinType values to real-world modes: normal (one-click), location, code, and photo, which naturally hints at which parameters are relevant for each mode. It does not explicitly map modes to required parameters, but it adds significant meaning beyond the bare 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 states a specific verb and resource: '学生签到' (student sign-in), and lists the four distinct sign-in modes: normal, location, code, and photo. This makes the tool's purpose immediately clear and distinguishes it from the sibling tools related to courses, homework, exams, and materials.
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 clearly implies the tool is used when a student needs to sign in to an activity, and the mode list gives some usage context. However, it does not explicitly say when each mode should be chosen, nor does it name alternatives or exclusions, such as prerequisites like needing an activityId.
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 的情况下，描述明确声明“只读取，不进入答题”，说明了操作是只读且不会进入答题流程，这对 agent 选择和执行非常重要。虽未提及认证或频率限制，但对一个列表工具而言已经提供了关键行为信息。
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?
描述只有一句中文，先说明核心动作，再补充输出内容和只读行为，信息密度高且没有冗余。每个部分都有价值，结构紧凑。
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?
工具只有一个参数且有输出 schema，描述已覆盖用途、输出内容和只读行为，整体较完整。但 courseRef 参数语义缺失，也缺少与其他列表工具的使用边界说明，因此仍有明显缺口。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入 schema 中 courseRef 没有任何描述，schema description coverage 为 0%，描述也没有说明 courseRef 的格式、取值来源或具体含义。仅凭“课程考试”猜测 courseRef 是课程标识，缺少足够的参数语义支持。
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?
描述明确指出操作动词“列出”、资源“课程考试”以及返回内容“标题/状态/入口链接”，用途非常明确。它与兄弟工具如 cx_s_list_homeworks、cx_s_list_chapters 通过“考试”这一具体资源自然区分开。
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?
描述隐含了使用场景：需要列出课程考试时使用此工具，但没有明确说明何时不应使用或应改用其他兄弟工具。缺少与 cx_s_list_homeworks 等列表类工具的显式对比或排除条件。
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'import' and describes the input, but does not state whether importing cookies overwrites the current session, whether cookies are validated, or what side effects occur. This is a meaningful gap for a session-affecting tool.
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-structured: action and source first, then parameter format, then use cases. Every sentence adds useful information and there is no redundant 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?
For a one-parameter tool with an output schema, the description provides the essential input format and use cases. The main missing context is the session-side-effect behavior, but basic invocation is adequately covered.
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 schema only defines a top-level 'cookies' array of arbitrary objects with 0% description coverage. The description compensates by specifying the expected item shape: [{name,value,domain?,path?}], and explains how to obtain the cookies. It does not define value types or required fields inside each item, but it provides enough to construct a valid call.
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: importing 学习通 (Chaoxing) cookies from a browser, and specifies the exact input format. No sibling tool handles cookie import, so it is easily distinguished from cx_login and other session 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 explicitly gives applicable scenarios: when the platform forces secondary verification or when password login is restricted by risk control. It does not explicitly mention alternatives or when not to use it, but the stated conditions are sufficient to guide 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?
With no annotations, the description must carry behavioral disclosure. It does disclose that the check works by reading the personal-space homepage, implying a read-only operation, but it does not mention prerequisites like valid cookies or failure behavior. For a status-check tool this is reasonable but not comprehensive.
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?
A single compact sentence that leads with the core purpose and adds the determining mechanism in a parenthetical. Every word earns its place with no repetition or filler.
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?
This is a simple zero-parameter check with an output schema present, so the description does not need to explain return values. The only notable gap is explicit usage guidance, but that is a minor omission given the low complexity.
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 tool has zero parameters and the schema already reflects this with 100% coverage. The description does not need to explain parameter semantics; the baseline for zero parameters is 4.
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 a specific verb ('检查'/'check') and resource (Chaoxing login state), and the parenthetical clarifies the mechanism by reading the personal-space homepage. This clearly distinguishes it from sibling tools like cx_login, cx_logout, and cx_import_cookies.
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 intended use is implied by the name and description: verify whether the existing session is valid. However, there is no explicit statement of when to call it, such as before other operations, or when to prefer login/import_cookies/logout instead, leaving some inference to the agent.
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?
With no annotations, the description carries the behavioral burden and does a solid job: it discloses role-dependent behavior (student vs teacher) and explains the significance of the returned IDs. It does not mention authorization or side effects, but for a list operation these are less critical. This exceeds the minimum by adding meaningful 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 a single concise sentence that front-loads the primary action and result. It includes the essential payload (three IDs) and the downstream purpose without wasted words. Every clause contributes useful information.
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?
For a parameterless list tool with an output schema, the description covers the necessary context: what is listed, how results differ by role, and why those results matter for later operations. There are no missing parameters to explain, and the output schema handles return structure. The description leaves no critical gap for an agent to call this tool correctly.
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 tool has zero parameters, so the baseline is 4; the schema already fully covers parameter needs. The description adds value by clarifying the output IDs and their role in future operations, though there are no parameters to describe. No parameter semantics gap exists.
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 '列出' with a clear resource '学习通课程' and distinguishes student vs teacher returns. It also names the exact IDs returned (courseId/clazzId/cpi), making the tool's purpose unambiguous. This clearly differentiates it from general 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 this is the starting point for all course-related operations by stating that subsequent operations depend on the three IDs. However, it does not explicitly mention when to use this over the sibling cx_s_list_learning_courses or provide exclusion criteria. Usage is reasonably inferable but not made explicit.
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?
With no annotations, the description carries the full behavioral burden and does disclose a concrete side effect: it deletes the local cookie file. It also indicates the logout action itself. It does not discuss idempotency or whether a server session is invalidated, but the recorded side effect is the most important disclosure.
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?
A single, front-loaded sentence that states the primary action and the side effect with no wasted words.
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?
For a parameterless logout tool with an output schema available, the description is complete enough: it names the action and the destructive local side effect. No other context is necessary for an agent to invoke it correctly.
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 tool has zero parameters, so the empty schema fully covers parameters. The description correctly adds no parameter details because none exist; the zero-parameter baseline of 4 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 a specific action: exit/log out of 学习通 and delete the local cookie file. This unambiguous verb+resource combination distinguishes it from sibling tools like cx_login and cx_session_status.
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 intended use is implied by the verb '退出' (logout), so an agent can infer when to call it. However, the description does not explicitly state when not to use it or name alternatives such as cx_session_status for checking login state.
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?
No annotations are provided, so the description carries the transparency burden. It clearly frames the tool as a read-only listing operation and discloses the exact fields returned and their purpose for follow-up calls. It does not mention authentication prerequisites or error behavior, but for a simple no-parameter list operation this is reasonably transparent.
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 concise sentence that states what is listed, which fields are returned, and why those fields matter for later steps. Every clause earns its place and there is no redundant wording.
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 zero-parameter tool with an output schema present, the description provides the essential context: what is returned and why the identifiers are useful. It could mention authentication requirements or give an example downstream operation, but the definition is functional for an agent deciding to call it.
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 tool has zero parameters and schema description coverage is 100%, so the description cannot add parameter-level meaning. The baseline 4 is appropriate because there are no parameters to document.
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 '列出' with a clear resource, '我学的课', and enumerates the key returned identifiers: courseId, clazzId, cpi, and teacher name. This distinguishes it from sibling cx_list_courses by emphasizing the user's own enrolled courses rather than a generic course 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 phrase '后续操作用这些 ID 定位' gives clear context that this tool is meant to be called first to obtain IDs needed by downstream operations. It does not explicitly compare against alternatives or state when not to use it, but the intended usage is clear.
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?
With no annotations, the description carries the behavioral burden. It explicitly flags submit=true as '★高影响', states that the first call returns confirmToken, and requires a second call with the token plus identical parameters before the submission happens. It does not mention auth prerequisites or irreversibility in detail, but the core side-effect and confirmation mechanism are disclosed.
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 whole usage contract is delivered in one dense, well-ordered sentence: safe mode first, high-impact mode second, then the answers format. Every clause earns its place and the important warning is starred and 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?
Given a 5-parameter mutation tool with no annotations, the description covers the safety profile, the two-step confirmation, and the answer payload. An output schema exists, so return details are covered elsewhere; the main missing context is where courseRef and workUrl come from.
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?
Schema description coverage is 0%, so the description must add parameter meaning, and it does: it explains the submit boolean's semantics and gives the exact answers array format [{stem, answer}]. The confirmToken flow is also described. However, courseRef and workUrl are left unexplained, which is a small but real gap.
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 '作业作答' (homework answering/submission) and then defines the two modes: submit=false is draft and submit=true is official submission. This gives a specific action on a specific resource and makes it clear why this tool exists alongside read-only siblings like list_homeworks and get_homework_detail.
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?
It gives clear context for when to use each mode: use submit=false for safe draft saving and submit=true for high-impact final submission, with a confirmation step. It does not explicitly name alternative tools or say when not to call this tool, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so well. It reveals that the password is only used in memory, is never logged or returned, and specifies the exact return code login_verification_required in the MFA case. This is meaningful, non-obvious 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 only two sentences yet covers purpose, security behavior, a conditional return value, and an alternative tool. It is front-loaded with the main purpose and contains no filler, so every sentence earns its place.
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?
For a simple login tool with two self-explanatory parameters and an output schema present, the description is complete. It covers success prerequisites implicitly, security handling, MFA behavior, and the fallback to cx_import_cookies, leaving no critical gap for an agent to call 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 schema has no descriptions and 0% coverage, so the description must compensate. It adds security-relevant context about the password parameter, but it does not explain parameter formats, constraints, or the meaning of username beyond what the name already implies. The parameters are obvious enough that this is adequate but not rich.
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 logs into Xuexitong/Chaoxing with a username and password, using a specific verb and explicit resource. It also distinguishes itself from the sibling cx_import_cookies by describing the MFA fallback path, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit conditional usage rule: if two-step verification is required, the agent should guide the user to log in via browser and then use cx_import_cookies instead. This directly tells the agent when to use this tool and when to switch to an alternative.
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

chaoxing-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![chaoxing-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/OSSKn4w7/chaoxing-mcp/badges/card.svg)](https://glama.ai/mcp/servers/OSSKn4w7/chaoxing-mcp)

Score Badge

Copy to your README.md:

[![chaoxing-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/OSSKn4w7/chaoxing-mcp/badges/score.svg)](https://glama.ai/mcp/servers/OSSKn4w7/chaoxing-mcp)

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/OSSKn4w7/chaoxing-mcp'

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