Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@hdu-ics-mcp-server What are my courses and exams today?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
将杭电助手 ICS 日历订阅接入支持 MCP 的客户端，查询杭电课程、考试和校园日程。
# 安装依赖
npm install
# 配置 ICS 订阅地址
cp .env.example .env
# 编辑 .env，填入你的 ICS URL
# 可选：调整时区和缓存时间
# 构建
npm run buildRelated MCP server: public-calendar-mcp
{
"mcpServers": {
"hdu-courses-and-exams": {
"command": "node",
"args": ["/absolute/path/to/hdu-ics-mcp-server/dist/index.js"],
"env": {
"ICS_URL": "https://api.hduhelp.com/calendar/schedule?staffId=xxxxxxxxxx"
}
}
}
}xxxxxx为你杭电助手订阅链接中的部分
也可以不写 env，改用项目根目录的 .env 文件配置 ICS_URL。
默认按 Asia/Shanghai 时区解析“今天 / 未来 N 天”，可用 CALENDAR_TIMEZONE 覆盖。
ICS 缓存策略为“同一用户标识优先复用缓存 + 每天首次访问强制刷新 + 4 小时过期刷新”，刷新失败时回退到上次成功缓存。
打开 Cherry Studio，进入 设置 → MCP 服务器
点击 添加服务器，填写以下信息：
名称: hdu-courses-and-exams
命令: node
参数: /absolute/path/to/hdu-ics-mcp-server/dist/index.js
环境变量: 添加 ICS_URL，值为 https://api.hduhelp.com/calendar/schedule?staffId=xxxxxx
xxxxxx为你杭电助手订阅链接中的部分
保存后即可在对话中使用日历相关工具
适合回答“今天有什么课”“这周有哪些考试”“搜索某门课或考试”等校园日程问题。
工具 | 说明 | 参数 |
| 获取今天的杭电课程、考试和日程安排 | 无 |
| 获取未来 N 天的杭电课程、考试和日程安排（含今天） |
|
| 按课程名、考试名、地点或描述搜索杭电日程 |
|
变量 | 说明 | 默认值 |
| ICS 订阅地址 | 无 |
| 日历展示与日期范围计算时区 |
|
| ICS 拉取缓存时长（毫秒） |
|
对 Claude 说：
"今天有什么课？"
"这周有哪些课程和考试？"
"搜索高等数学相关的课程或考试"
获取今天的杭电课程、考试和日程安排
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It reveals that the tool aggregates three categories (courses, exams, schedule) but says nothing about read-only safety, authentication, data source, timezone/semester handling, or return format for a no-argument query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-formed sentence that front-loads the verb and enumerates exactly what is returned. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema query the description is nearly complete — it conveys the resource and the time scope. It still omits the environmental assumptions (whose schedule, which timezone, how the day boundary is determined) that an agent would need to interpret 'today' correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter syntax for the description to supply. Per the baseline rule for 0-param tools, a 4 is appropriate; the description adds only the implicit 'today' scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('获取' = get, '课程、考试和日程安排' = courses, exams and schedule) scoped to 'today', which distinguishes it from the 'upcoming' sibling. However it never names the siblings explicitly, so an agent must infer the difference from the temporal qualifier alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no mention of alternatives such as get_upcoming_courses_and_exams or search_courses_and_exams. The word 'today' implicitly contrasts with 'upcoming', but the agent receives no stated rule for choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取未来 N 天的杭电课程、考试和日程安排
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | 查询天数，默认 7 天 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, yet it discloses nothing beyond the basic query intent—no return format, no data source, no auth or rate-limit notes. It is a minimal read-only query with essentially no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word contributes to stating the purpose and scope, making it appropriately sized for a one-parameter query tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with no output schema and no annotations, the description covers the basic resource types returned (courses, exams, schedule). However, it omits whether today is included, how the day window is bounded, and any return format detail, leaving minor gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'days' already has 100% schema description coverage ('查询天数，默认 7 天'). The description's phrase '未来 N 天' restates the day-window concept without adding syntax, boundary behavior, or meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource in Chinese: '获取' (get) and '未来 N 天的杭电课程、考试和日程安排' (future N days of HDU courses, exams, and schedule). It implicitly distinguishes itself from 'get_today_courses_and_exams' by scoping to '未来 N 天' rather than today, but it does not explicitly name any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only states what the tool does; it gives no when-to-use guidance, no when-not-to-use, and does not point to alternatives like 'get_today_courses_and_exams' or 'search_courses_and_exams'. Usage must be inferred entirely from the tool name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按关键词搜索杭电课程、考试和日程（搜索名称、地点、描述）
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 搜索关键词 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses which fields are searched, which is useful, but says nothing about return format, result limits, ordering, or whether the search is case/substring sensitive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler; every clause (resource and searched fields) earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter search tool with no annotations and no output schema, the description covers the core purpose but leaves the agent uninformed about result shape and search behavior. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single required 'keyword' parameter already documented as 搜索关键词. The description adds only the field scope (name/location/description) and no syntax or format guidance, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (搜索/search) and resource (杭电课程、考试和日程), plus the fields searched (名称、地点、描述). It is clear what the tool does, though it never explicitly distinguishes itself from the sibling get_today/get_upcoming tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this is the keyword-based search path versus the temporal siblings. However, there is no explicit statement of when to prefer this over get_today_courses_and_exams or get_upcoming_courses_and_exams, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.0get_today_courses_and_examsget_upcoming_courses_and_examssearch_courses_and_examsScored across 3 tools
The three tools split cleanly along time/query axes: today, next N days, and keyword search. The only mild overlap is that 'today' is a special case of 'upcoming' (N=1), which an agent could conflate, but the descriptions make the intent clear.
All three follow a strict verb_noun pattern (get_today_..., get_upcoming_..., search_...). Consistent, predictable, and easy to pattern-match.
Three tools is lean but well-matched to a read-only schedule/exam lookup domain. It is on the thin side (no detail or date-specific query), but each tool earns its place.
Core read workflows (today, upcoming, search) are covered, but there is no way to query an arbitrary date or date range, nor to fetch a single course/exam's full detail. These are workable gaps for an agent but limit the surface.
Extracts calendar events from natural-language text, with .ics and calendar links.
Calendar API for AI agents: events, availability, Google/Microsoft setup, scheduling, and iCal.
Schedule and manage Google Calendar events directly from your workspace. Check availability, view…
Manage Google, Outlook & Apple calendars and create private sync rules from chat.