Click on "Install 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., "@bit101-mcp 总结今天的 BIT101 帖子"
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.
A local, read-only Model Context Protocol (MCP) service for Beijing Institute of Technology students. It converts BIT101 community content, course reviews, personal schedules, grades, and Lexue calendar into structured data that agents can easily understand, letting you ask questions directly in natural language.
[!IMPORTANT] This project is an unofficial community project and is not affiliated with Beijing Institute of Technology or the official BIT101. Windows has been tested on real hardware for the main workflows; Fedora 43 + niri has been verified to run; the project is still at the MVP stage. Please read Authentication, Security, and Privacy before use.
Summarize today's BIT101 posts, or search historical discussions by keyword
Look up courses, instructors, and student reviews from past years
Get today's, this week's, next week's, or a specified semester's schedule
Query grades, credits, class averages, and highest scores (when provided upstream)
Query Lexue calendar events for an upcoming period
Combine data from different sources to answer questions, such as "What do people think of the instructors for my courses next semester?"
All tools are read-only. The project cannot post, like, comment, submit assignments, change grades, or modify any school data.
Related MCP server: MCP-Server-CollageAI
The following screenshots are from real calls on Windows using the OpenCode cli. The specific answers are generated by the model in use based on the data returned by MCP, do not represent the views of the project author, and may change as the model and data update.
The agent calls list_today_posts to get the day's posts, then generates a brief summary based on titles, content, and engagement.
The agent first searches for the courses corresponding to the instructor, then calls get_course_reviews to aggregate course metadata, ratings, comments, and historical information.
When the course database has no exact match, the agent can continue searching BIT101 posts and read relevant discussions, demonstrating the effect of chaining multiple MCP tools together.
The agent can query Lexue events within 7 to 90 days. A valid calendar with no upcoming tasks returns an empty list normally, rather than misjudging "no tasks" as an interface failure.
Currently recommended environment:
Windows 10/11, or Linux with a desktop browser and a usable system keyring (Fedora 43 + niri has been tested)
Python 3.11 or higher
A client supporting local stdio MCP, such as Codex, OpenCode, Cursor, or Claude Code
A BIT101 account
For querying schedules and grades, a Beijing Institute of Technology unified identity authentication account is also required; some logins may require SMS verification
For querying Lexue, you need to export a private calendar subscription URL from Lexue once
If your agent can execute terminal commands and modify its own MCP configuration, you can directly send the following text to it:
请帮我安装并配置 BIT101 MCP：
https://github.com/tiny-paris/BIT101-mcp
要求：
1. 先阅读仓库 README，尤其是“认证、安全与隐私”部分，并告诉我它会访问哪些服务。
2. 检查本机是否安装 Python 3.11+、Git 和 uv；缺少时说明后再安装。
3. 优先使用以下命令安装为用户级工具：
uv tool install "git+https://github.com/tiny-paris/BIT101-mcp.git"
4. 识别我当前使用的 MCP 客户端，将 bit101-mcp 配置为用户级/全局 stdio MCP，
名称使用 bit101，单次工具执行超时至少设置为 360 秒。
5. 如果找不到命令，运行 uv tool dir --bin，并在 MCP 配置中使用
bit101-mcp（Windows 为 bit101-mcp.exe）的绝对路径。
6. 重启或重新加载 MCP，验证服务器已连接并能列出工具。
7. 不要在聊天、命令行参数、配置文件或环境变量中向我索要或写入账号、密码、
短信验证码、Cookie、token 或乐学订阅 URL。需要认证时，只让我在 MCP 自动打开的
127.0.0.1 临时页面中操作。
8. 不要修改默认上游地址。完成后告诉我修改了哪些配置文件以及验证结果。After the agent completes the installation, simply ask "Summarize today's BIT101 posts" in a new conversation to trigger the first on-demand authentication.
Once the repository is public, you can run:
git clone https://github.com/tiny-paris/BIT101-mcp.git
cd BIT101-mcp
uv sync --all-groups
uv tool install .uv tool install . installs bit101-mcp as a user-level command. You can use the following command to view uv's executable directory:
uv tool dir --binIf the MCP client cannot find bit101-mcp, restart the client, or use the absolute path of bit101-mcp.exe in that directory in the configuration.
For development or testing, you can also run without installing:
uv sync --all-groups
uv run bit101-mcpAfter a stdio MCP starts normally, it quietly waits for protocol messages. It is normal for it to look "stuck." Do not treat it as an ordinary interactive command, and do not enter account credentials into its terminal.
[!NOTE] A simple
uvx bit101-mcpwill only be supported after the project is published to PyPI. The current README does not assume a PyPI package already exists.
The project declares 7 runtime direct dependencies. They are not all "mandated by the MCP protocol," but rather the components each currently needed for full functionality:
Dependency | Purpose in the Project | Can It Currently Be Removed? |
| MCP stdio server, tool registration, context, and protocol types | No; this is the core dependency |
| Async/sync HTTPS client for accessing BIT101, BIT-Login, and the Lexue calendar | No; all data and authentication require network access |
| Saves sessions and the Lexue subscription URL to the OS credential store | No; without it, sessions cannot be safely reused across processes |
| Validates and parses ICS/iCalendar exported from Lexue | No; used by the Lexue feature and at startup import |
| Expands recurring rules (RRULE) in the Lexue calendar | No; needed for recurring events |
| MCP tool parameter ranges and JSON schema, e.g., post count, week offset, query days | No; used directly in the source, and the MCP SDK is also based on it |
| Provides the | Not recommended to remove; otherwise some Windows/Python environments cannot correctly compute "today" and teaching weeks |
Therefore, for the current single-package version, all 7 are runtime dependencies; but from a functional standpoint, icalendar and python-dateutil only serve Lexue. If split into optional features in the future, they could become extra dependencies. Splitting them now would increase installation and error-reporting complexity, and the size savings would be very limited.
You will also see indirect dependencies such as anyio, httpcore, and certifi in uv.lock. They are pulled in automatically by the libraries above, are not top-level components actively called by the project, and should not be manually installed or removed on their own.
The following dependencies are only used for development and release, and will not be installed as ordinary runtime dependencies:
Dependency | Purpose |
| Automated testing |
| Code linting and formatting |
| Building source distributions and wheels |
The first school authentication can take up to a few minutes, so it is recommended to set the single tool call timeout to 360 seconds. After configuration, restart the MCP client so it starts a new service process.
The Codex CLI, Codex IDE extension, and the Codex host in the ChatGPT desktop app share the MCP configuration in config.toml. See the official Codex MCP documentation.
First add it via the CLI:
codex mcp add bit101 -- bit101-mcp
codex mcp listThen check the user-level %USERPROFILE%\.codex\config.toml and add the tool timeout:
[mcp_servers.bit101]
command = "bit101-mcp"
tool_timeout_sec = 360If you only want to enable it in a specific trusted project, you can put the same configuration in that project's .codex/config.toml. The user-level configuration works in any directory and in new conversations.
If the command is not in Codex's PATH, you can change it to an absolute path:
[mcp_servers.bit101]
command = 'C:\path\to\bit101-mcp.exe'
tool_timeout_sec = 360This project has completed Windows real-hardware testing using the traditional OpenCode configuration below. Placing it in opencode.json at the project root only applies to that project; to use it in any directory, place it in the user-level ~/.config/opencode/opencode.json (on Windows this usually corresponds to %USERPROFILE%\.config\opencode\opencode.json).
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"bit101": {
"type": "local",
"command": ["bit101-mcp"],
"enabled": true,
"timeout": 360000
}
}
}Verify the connection:
opencode mcp listIf it can only start in the source directory, it is usually because the configuration uses a relative command and there is no global installation. Install bit101-mcp, or change command to the absolute path of .venv\Scripts\bit101-mcp.exe.
OpenCode V2 has a different configuration structure: services are under mcp.servers and the execution timeout is under mcp.timeout.execution. Please refer to the official OpenCode MCP documentation:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"timeout": {
"execution": 360000
},
"servers": {
"bit101": {
"type": "local",
"command": ["bit101-mcp"]
}
}
}
}According to the Cursor MCP documentation, global configuration goes in ~/.cursor/mcp.json and project configuration goes in .cursor/mcp.json:
{
"mcpServers": {
"bit101": {
"command": "bit101-mcp",
"args": []
}
}
}After saving, restart Cursor and confirm that bit101 is enabled in the agent's available tools list.
Following the Claude Code MCP documentation, add a user-level stdio service:
claude mcp add --scope user bit101 -- bit101-mcp
claude mcp listOther MCP clients only need to configure a local stdio process:
{
"command": "bit101-mcp",
"args": []
}Do not put account names, passwords, cookies, tokens, or Lexue URLs into MCP configuration, environment variables, or tool parameters.
After configuration, just ask questions directly in the agent conversation. No need to manually start a background service. For example:
总结一下今天 BIT101 都有哪些帖子。
查找最近关于“数据结构”的讨论。
如何评价某某老师的某门课？请区分普遍评价和少数意见。
查找“特立自动化”相关讨论，并列出信息来源。我今天有什么课？
我下周有什么课？按实际日期和开始时间排序。
列出本学期完整课表。
列出我的所有成绩，包括课程、学期、学分、成绩、班级平均分和最高分。When asking about "this week/next week," the server calculates the exact week based on the current date and returns complete times such as starts_at and ends_at; the agent does not need to guess teaching weeks or period times on its own.
未来 14 天有哪些乐学任务？按截止时间排序。
看看未来 30 天的乐学日历。Tool | Purpose | Authentication Required |
| Get BIT101 posts published today in the Shanghai timezone | BIT101 |
| Search BIT101 posts | BIT101 |
| Read a specific post and related information | BIT101 |
| Search courses and instructors | BIT101 |
| Aggregate course, instructor, review, and historical course information | BIT101 |
| Get today's courses | School unified authentication |
| Get a dated schedule for this week, next week, or a relative week | School unified authentication |
| Get the full schedule for the current or a specified semester | School unified authentication |
| Get grades and available class statistics | School unified authentication |
| Parse Lexue calendar events for the next 1 to 90 days | School authentication + Lexue subscription URL |
Successful results are uniformly formatted as:
{
"ok": true,
"data": {}
}Failed results do not include upstream stack traces or authentication information:
{
"ok": false,
"error": {
"code": "UPSTREAM_UNAVAILABLE",
"service": "bit101",
"message": "BIT101 is temporarily unavailable.",
"retryable": true
}
}The core is divided into four layers:
MCP tool layer: Only exposes user-facing concepts such as posts, courses, schedules, grades, and tasks; never exposes cookies, challenge tokens, or internal service identifiers.
Client layer: Handles the BIT101 API and the school data gateway separately; on request failure, determines whether the session has expired and performs only one recoverable retry.
Normalization layer: Converts different upstream formats into stable, JSON-friendly fields; handles Shanghai timezone dates, teaching weeks, course times, grades, and ICS event parsing.
Authentication and storage layer: Opens a local page only when needed; passwords never enter MCP parameters; only reusable sessions are saved after success.
MCP uses the stdio transport. Standard output only carries MCP protocol data; runtime logs are written only to standard error, preventing logs from corrupting protocol communication.
Browser cookies belong to the browser's own security space, and MCP is an independent local process. The project deliberately does not read Chrome/Edge cookie databases and does not require installing a browser extension. This adds one extra initial authentication, but avoids MCP scanning all of the user's browser credentials.
Opening a new agent conversation does not by itself clear the login state. MCP reads and validates the saved session at startup; it only re-authenticates when the session does not exist, the upstream determines it is invalid, the authentication gateway's temporary challenge has expired, or the system credential store is unavailable.
On the first call to a community tool:
MCP starts a temporary page on a random port at 127.0.0.1.
The user enters their student ID and BIT101 password on the local page.
The local process handles the password according to the existing BIT101 login protocol and requests the BIT101 API over HTTPS.
After successful login, only the returned BIT101 session is saved to the system credential manager; the raw password is not persisted.
The temporary page closes, and the original tool call continues.
Schedules and grades come from the school's personal data capability and are not the same "key" as the BIT101 community session. On the first call, the local page collects the unified authentication account, password, and an SMS verification code when needed, and submits them over HTTPS to the existing BIT-Login REST gateway. MCP saves the short-term challenge session returned by the gateway, not the school password.
The current BIT-Login REST gateway does not provide a Lexue calendar interface that this project can call, and the project does not reimplement the school's CAS/SSO. Therefore, the MVP requires the user to generate a private subscription URL on the Lexue Calendar → Export Calendar page and paste it once on the local connection page.
The connection page actually downloads and validates the iCalendar content; only a valid subscription shows Connected. Ordinary calendar/view.php pages are rejected. The subscription URL does not enter the agent or MCP tool results and is saved to the system credential manager. A valid calendar with no upcoming events returns an empty list.
This project reduces the risk of passwords entering the agent, chat history, and logs, but cannot promise "zero risk." Installing a local MCP is equivalent to installing a local program that can access the network; users need to trust the project source code, installation packages, dependencies, and the configured remote authentication services.
Two statements in particular need to be distinguished:
Passwords are not sent to the agent/LLM: this is an explicit boundary implemented by this project.
Passwords only exist on this machine: no. The school unified authentication password must be submitted by the local MCP over HTTPS to the configured remote BIT-Login gateway to complete authentication.
Information | Who Has Access | Is It Persisted? |
BIT101 password | Local authentication code; submitted to the BIT101 API per the upstream protocol | Password not saved |
School unified authentication password | Local authentication code and the configured BIT-Login gateway | Not saved |
SMS verification code | Local authentication code and the BIT-Login gateway | Not saved |
BIT101/school session | Local MCP and the corresponding upstream | OS credential store |
Lexue private subscription URL | Local MCP and the | OS credential store |
Posts, courses, schedules, grades, Lexue events | MCP and the current agent | Enters the current agent context |
Default upstream addresses:
BIT101 API: https://bit101.flwfdd.xyz
BIT-Login REST: https://login.bit101.flwfdd.xyz
HTTPS prevents ordinary network eavesdropping but does not replace trust in the server operator. Users who are uncomfortable with their school password passing through a remote gateway should not enable the schedule and grade tools.
The temporary HTTP service only binds to 127.0.0.1 and uses a random port assigned by the operating system.
Each authentication uses a 256-bit random state and constant-time comparison to resist forged submissions.
The page disables caching, external content, iframes, referrers, and MIME sniffing.
The page stops listening after success, cancellation, or timeout.
Passwords and verification codes are not written to files; the code clears relevant variable references as soon as possible after the request.
Sessions are written to the OS credential store via Python keyring (Windows Credential Manager, or the Secret Service/keyring backend on Linux); when unavailable, they are only kept in the current process memory, with no fallback to plaintext files.
Logs redact passwords, verification codes, cookies, Bearer tokens, and Authorization headers.
The Lexue URL must use HTTPS under the bit.edu.cn domain and must return valid iCalendar.
All tools are marked read-only and provide no ability to modify school or community data.
Only install from trusted repositories or trusted release pages, and check the source code and release hashes where possible.
The local authentication page address should start with http://127.0.0.1:<random port>/connect.
Never send passwords, verification codes, cookies, tokens, or Lexue URLs in the agent chat box, MCP parameters, issues, or logs.
Do not use personal school accounts on untrusted public computers.
The Lexue subscription URL is a private link that grants read access as soon as it is obtained; protect it like a password, and regenerate it in Lexue if you suspect it has leaked.
When querying grades or schedules, the corresponding data is provided to the current agent. Decide whether to enable these tools based on the data policies of the model and client you use.
On Windows, open Control Panel → Credential Manager → Windows Credentials; on Linux, open the Secret Service management tool used by the current desktop environment (commonly GNOME Keyring or KDE Wallet). Delete the following entries with the service name bit101-mcp:
bit101-session
school-session
lexue-calendar-url
After deletion, the next call to the corresponding tool will re-authenticate. Uninstalling the Python package does not automatically delete these system credentials. If Linux has no available keyring backend, sessions are only kept in the current process memory and you will need to log in again after restarting MCP.
Only non-secret parameters can be configured via environment variables:
Variable | Default value | Purpose |
|
| BIT101 API root URL |
|
| BIT-Login REST root URL |
|
| Single upstream HTTP timeout, in seconds |
|
| Maximum wait time for the local authentication page, in seconds |
Credentials and sessions cannot be configured via tool parameters or environment variables. Changing the upstream address means trusting a new service operator; use with caution.
No. After installing the command with uv tool install . and writing the MCP into the client's user-level configuration, you can use it from any directory. The opencode.json, .cursor/mcp.json, or .codex/config.toml in the project root only apply to that project.
Authentication is triggered on demand. The first post query needs a BIT101 session; the first schedule/grade query needs a school session; the first Lexue query also needs a private calendar subscription. Passwords and subscription URLs cannot go through the chat, so a temporary local page is used to collect them.
The webpage session is stored in browser cookies. MCP does not read browser cookies, so it needs to establish its own minimal session. This sacrifices one initial login convenience but avoids directly accessing all of the browser's login data.
A new conversation does not proactively clear sessions, but MCP validates the upstream session. It will log in again when the session expires, is revoked by the server, the authentication gateway challenge becomes invalid, or the system credential store is unavailable. If you are prompted again immediately after a successful login and restart, check whether a bit101-mcp entry exists in the system credential store.
Connected, but why are there no tasks?If the subscription URL passes iCalendar validation, an empty list usually just means there are genuinely no events in the selected time range. You can expand the query range from 7 days to 30 days to confirm.
The first school authentication, SMS verification, and grade detail retrieval can take a while. Set the MCP tool timeout to 360 seconds and wait for the current call to finish; do not retry multiple school tools at the same time.
bit101-mcp command cannot be found?Run uv tool dir --bin to find the installation directory, add it to PATH, or directly fill in the absolute path of bit101-mcp.exe in the MCP configuration. Restart the client after making changes.
Code | Meaning |
| A BIT101 session needs to be established |
| A school session needs to be established |
| The saved session has expired |
| Login was unsuccessful or the credentials were not accepted upstream |
| The local authentication page wait timed out |
| The Lexue subscription does not exist, is invalid, or is not a valid calendar |
| The specified post or other record does not exist |
| The upstream service is temporarily unavailable; retry later |
| The upstream returned unrecognizable data |
All errors are sanitized and do not return passwords, cookies, tokens, Authorization headers, raw stack traces, or complete sensitive requests.
Project structure:
src/bit101_mcp/
├── server.py # MCP 入口、工具注册和服务器说明
├── tools/ # Agent 可见的只读工具
├── clients/ # BIT101 与学校上游客户端
├── auth/ # 本地浏览器认证、状态机和凭据存储
├── models/ # 数据标准化、周次和 ICS 解析
└── logging_utils.py # stderr 日志和秘密脱敏Install development dependencies and run checks:
uv sync --all-groups
uv run ruff check .
uv run ruff format --check .
uv buildBefore release, maintainers use mock tests that are not distributed with the public repository to verify data normalization, authentication state, secret redaction, and retry flows; these tests do not require real accounts. Real-account integration testing remains manual and optional, and test credentials should not be committed to the repository or CI.
Thanks to the BIT101 project and all its contributors. The community, course reviews, campus data interfaces, and authentication tools that seniors have maintained over the years have brought great convenience to students' campus life and also provided an important foundation for this project.
This project specifically references or uses interfaces and documentation from the following projects:
BIT101 MCP is an independently developed unofficial MCP client that interacts with related services through network interfaces. The MIT License in this repository applies only to this project's original code and does not replace or alter the licenses of any upstream projects.
Windows has been tested on real hardware for the main workflows; Fedora 43 + niri has been verified to run, but other Linux desktop environments have not been individually verified.
Lexue still requires manually pasting an exported private calendar subscription URL once.
The school session validity is determined by the upstream gateway and long-term login-free access cannot be guaranteed.
Grade averages and highest scores depend on whether the upstream provides per-course details.
PyPI packages and standalone Windows executables have not yet been released.
No write operations are provided.
This project is licensed under the MIT License. You are welcome to use, modify, distribute, and submit improvements, provided that the copyright and license notices are retained.
We welcome Issues and Pull Requests. When reporting a problem, please provide:
Operating system, Python, uv, and MCP client versions
The tool name used and the sanitized error code
Whether a local authentication page appears
Reproducible steps
Do not submit student IDs, passwords, verification codes, cookies, tokens, full request headers, 乐学 URLs, or other personal information.
Aggregate course metadata, teachers, reviews, and historical score data.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | BIT101 course ID. | |
| comment_pages | No | Number of review pages to aggregate. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context that this is an aggregating read operation pulling several data categories, but it does not disclose details such as pagination behavior, rate limits, or the reach of 'historical score data'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence front-loads the action and lists the key result categories with no filler or redundancy. Every word contributes to understanding what the tool returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With read-only annotations, a full output schema, and fully documented parameters, the description is largely sufficient for an agent to invoke the tool correctly. The main gap is the lack of guidance for choosing this tool over sibling tools, though that is more a usage-rule concern than a completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both course_id and comment_pages are already well documented with types, defaults, and bounds. The description adds no additional parameter-specific meaning, so it meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('aggregate') and enumerates the returned resources ('course metadata, teachers, reviews, and historical score data'), making the tool's focus clear. It does not explicitly contrast with siblings like search_courses or get_scores, but the resource description is sufficiently unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus sibling tools such as search_courses, get_post, or get_scores. The description only states what it aggregates, leaving the agent to infer appropriate usage from the tool name and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one BIT101 post by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | BIT101 post ID. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint=true, covering the safety profile. The description adds minimal behavioral detail beyond this, but for a simple single-ID read operation, the core behavior is adequately conveyed. No hidden side effects or contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the action, the resource, and the selection criterion efficiently.
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 get-by-ID tool, the description, input schema, output schema, and annotations provide everything an agent needs to invoke it correctly. No additional context about return values or safety is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents post_id with its own description, so schema coverage is 100%. The description adds no additional parameter semantics beyond what the schema already provides, fitting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a specific resource ('one BIT101 post') with a precise selection mechanism ('by ID'). This clearly distinguishes it from sibling list/search tools and leaves no ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the proper usage: call this tool when you have a specific post_id and need exactly one post. However, it does not explicitly state when to use this tool instead of list_today_posts or search_posts, nor does it mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whole term only; for relative weeks use get_week_schedule; browser: do not retry.
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | Optional term code such as 2025-2026-1. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and world-openness. The description adds the non-obvious behavioral constraint 'Whole term only' and the retry guidance, which go beyond the structured metadata. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short clauses, each carrying distinct functional or operational information. It is front-loaded with the core scope ('Whole term only') and has 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?
Given the single optional parameter, full schema coverage, an output schema, and annotations covering safety, the description provides the remaining necessary context: scope, sibling routing, and a retry caveat. Nothing essential is missing for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single optional 'term' parameter, including its format, default, and example. The description does not add parameter-level detail, but with 100% schema coverage the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Get BIT schedule' and description 'Whole term only' make it clear the tool retrieves a schedule for a full term, distinguishing it from week-based schedule tools. It lacks an explicit verb in the description, but the name and title supply the action and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Whole term only') and directs users to a specific alternative ('for relative weeks use get_week_schedule'). It also adds the operational warning 'browser: do not retry', which is useful guidance for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return grades with class average/maximum when available; browser: do not retry.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, covering the safety profile. The description adds useful context with 'when available' and the operational note 'browser: do not retry,' but the browser note is terse and does not explain failure or retry semantics in detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that states the core behavior first. The 'browser: do not retry' clause is terse but adds an operational constraint without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool with an output schema, the description is nearly complete: it states what is returned and that class average/maximum may not always be present. The ambiguous 'browser: do not retry' note prevents a perfect completeness score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100%, so there is no parameter information the description needs to add. The baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Return grades' with an added detail about class average/maximum. This clearly identifies the tool's purpose and distinguishes it from the schedule, course, and post-related sibling 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?
There is no explicit guidance about when to use this tool versus alternatives, and no prerequisites or exclusions are stated. The name implies the use case, but the description does not actively help an agent decide between tool options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return today's classes. May open a browser for school login; wait, do not retry.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a concrete behavioral warning beyond the annotations: it may open a browser for school login, and the agent should wait and not retry. This is valuable context that readOnlyHint/openWorldHint do not fully convey. The instruction 'wait, do not retry' is slightly ambiguous, preventing a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core purpose is front-loaded, and the critical runtime warning follows immediately. Every word 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?
Given there are no parameters, an output schema exists, and annotations already cover read-only and open-world behavior, the description is complete for selecting and invoking the tool. The only behavioral nuance an agent needs—possible browser opening and no retry—is explicitly stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema covers 100% of them, so there are no parameter semantics the description needs to explain. The baseline of 4 for a zero-parameter tool is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and a precise resource ('today's classes'), making the tool's scope immediately clear. It also naturally distinguishes this tool from siblings like get_week_schedule and get_schedule by anchoring on 'today's'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving today's classes, but it never explicitly states when to use it versus alternatives such as get_week_schedule or get_schedule. The browser/login warning is behavioral guidance, not usage selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Lexue events; invalid subscriptions reopen browser setup; do not retry.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Future time window in days. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint annotations already present, the description still adds value by warning that invalid subscriptions can reopen browser setup and instructing not to retry. This exposes an important side effect beyond the standard annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact, front-loaded sentence: purpose first, then the critical retry warning. Every phrase earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-mostly tool with an output schema, the description covers the core action and the critical failure behavior. It could be more complete by explicitly saying the result is a list of upcoming Lexue tasks, but the name, title, and days parameter fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter, days, with a clear description ('Future time window in days'), so schema description coverage is 100%. The prose description adds no parameter-level detail, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action ('Return Lexue events') and the tool name/title specify 'upcoming Lexue tasks', which separates it from the post/course/schedule siblings. It is slightly vague because the description says 'events' rather than 'tasks' and does not explicitly mention the upcoming time window beyond the days parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance or comparison with sibling tools like get_today_schedule or list_today_posts. The only usage-related note is 'do not retry', which is a retry prohibition rather than guidance for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call for this/next/last week. Exact dates/times; browser may open; do not retry.
| Name | Required | Description | Default |
|---|---|---|---|
| week_offset | No | Week relative to current: 0=this, 1=next, -1=last. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior beyond annotations: 'browser may open' and 'do not retry'. Nothing contradicts 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences carry purpose, output character, a side-effect warning, and a retry instruction with no filler. The most important routing information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single optional parameter, an output schema, and read-only/open-world annotations, the description covers what to call, what kind of output to expect, and the notable side effect. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so week_offset is fully documented with its default, range, and meaning. The description only paraphrases this/next/last week and adds no parameter-specific details, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (a relative week's BIT schedule) and the action (get/call for this/next/last week), so an agent can tell what the tool does. It does not explicitly contrast with siblings like get_today_schedule or get_schedule, so it stops short of full differentiation.
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?
'Call for this/next/last week' provides a clear target use case, and 'do not retry' gives explicit invocation guidance. It lacks exclusions or named alternatives, such as pointing to get_today_schedule for today-only schedules, so it is not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return BIT101 posts created today in Asia/Shanghai time.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum posts to return. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this by saying 'Return'. It adds valuable context about the Asia/Shanghai timezone determining the day boundary. No contradictory or misleading behavior is stated, and the description does not claim anything beyond what the tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that front-loads the purpose, resource, and timezone. Every word is necessary and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with zero required parameters and an output schema present, the description fully covers the essential contextual detail: the resource, the time scope, and the timezone boundary. Nothing critical for invoking this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the only parameter 'limit' is fully documented in the schema as 'Maximum posts to return' with defaults and bounds. The description does not add additional parameter behavior beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return'), a clear resource ('BIT101 posts'), and an unambiguous scope ('created today in Asia/Shanghai time'). It distinguishes itself from siblings like search_posts and get_post by focusing on today's posts. The addition of the timezone disambiguates the meaning of 'today'.
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 clearly communicates that this tool returns today's BIT101 posts, implying it is the choice when the agent needs a list of posts from the current day in Asia/Shanghai time. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough relative to siblings such as search_posts and get_post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search BIT101 course and teacher records.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-based result page. | |
| limit | No | Maximum courses to return. | |
| order | No | rate | |
| query | Yes | Course or teacher search text. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description is not burdened with explaining safety behavior. It adds some scope context (courses and teacher records) but does not disclose additional behavioral traits such as matching behavior or ordering semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. It is front-loaded with the verb and target resource and 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?
Given the output schema, annotations, and parameter descriptions, the definition is largely complete for a search operation. The only notable gap is the absence of any usage guidance relative to sibling tools, but this does not prevent an agent from invoking the tool 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?
Schema description coverage is 75%: query, page, and limit have descriptions, and order has an enum. The description adds little beyond what the schema already says, though it does reinforce that queries can target both course and teacher records.
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 clear verb and resource: 'Search BIT101 course and teacher records.' This identifies the tool's scope and distinguishes it from siblings like search_posts, though it does not explicitly contrast itself with those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as search_posts or get_course_reviews. The resource scope is implied by the description, but no when-to-use or when-not-to-use context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search public BIT101 discussion posts.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-based result page. | |
| limit | No | Maximum posts to return. | |
| query | Yes | Search text. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, covering the operation's safety and dynamic nature. The description adds the 'public' scope and 'discussion posts' resource, which is useful context, but does not disclose additional behavioral details such as pagination behavior, result ordering, or real-time semantics beyond what annotations and schema 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the essential purpose immediately and does not repeat information already available in the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with three well-documented parameters, readOnly/openWorld annotations, and an output schema, the description is sufficient. An agent can correctly understand the tool's purpose and invoke it without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters (query, page, limit), so the description does not need to compensate. The description itself adds no parameter-level meaning, but with 100% schema coverage the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Search' and the resource 'public BIT101 discussion posts,' making the tool's purpose immediately evident. It distinguishes itself from sibling tools like list_today_posts and get_post by emphasizing search over listing or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for searching public posts by keyword, but it does not explicitly state when to use it instead of alternatives like list_today_posts or get_post. There is no exclusionary guidance or mention of alternatives, so the agent must infer usage from the name and description.
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. Dates show when Glama detected each change.
v0.1.0get_course_reviewsget_postget_scheduleget_scoresget_today_scheduleget_upcoming_lexue_tasksget_week_schedulelist_today_postssearch_coursessearch_postsEach tool maps to a distinct resource or time range, and the schedule tools are explicitly qualified as today, week, or whole term. The only mild overlap is between search_courses and get_course_reviews, but the descriptions help differentiate them.
Tool names consistently use a verb prefix (get, list, or search) followed by a lowercase snake_case noun phrase, such as get_course_reviews and list_today_posts. There is no mixed casing or inconsistent verb style.
Ten tools cover the main BIT101 areas—posts, courses, schedules, grades, and tasks—without feeling bloated. The additional schedule and post tools each serve a specific retrieval need, so the count is well-scoped.
The read-only surface is fairly complete for posts, courses, schedules, scores, and Lexue tasks. Minor gaps exist, such as arbitrary future-date schedule lookup and any write/submit endpoints, but these are likely outside scope and workarounds are available.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only IELTS and CELPIP question banks, learner practice, progress, scores, and feedback.
Read-only access to your own Pithflow meeting notes, transcripts, dictionary and usage.
Read-only Reddit search API for AI agents: posts, comments, comment trees, subreddit rules.
Search, read, cite, create, and safely update a user's private KeepFlash knowledge library.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tiny-paris/BIT101-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
