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., "@sjtu-pan-mcp 看看我交大云盘里有什么"
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.
⚠️ AI 辅助生成，谨慎使用
📢 免责声明：本项目与上海交通大学没有任何关系，是第三方个人开发者生成的非官方工具，不代表官方立场。
让 AI agent 直接浏览上海交通大学云盘（pan.sjtu.edu.cn）里的文件，并下载到本地。
基于对交大云盘 Web 前端实际接口的逆向（两层 API：user_token 会话层 → 空间 access_token 层），不接触账号密码，只复用一次扫码登录产生的会话。
适用任何支持 MCP 的客户端：ZCode、Claude Code、Claude Desktop、Cherry Studio 等。
工具 | 作用 |
| 弹出浏览器窗口扫码登录（jAccount），自动保存登录态 |
| 账户信息与登录态自检（用户、组织、空间列表） |
| 列出全部空间（个人空间/团队空间） |
| 列出某个目录下的文件和子目录 |
| 全局搜索文件（关键词） |
| 查看单个文件/目录的元信息 |
| 下载单个文件到本地 |
| 递归下载整个目录（保留子目录结构） |
Related MCP server: yifangyun-mcp-server
pip install "sjtu-pan-mcp[gui,cookie]"或从源码安装：
git clone https://github.com/Mccount666/sjtu-pan-mcp.git
cd sjtu-pan-mcp
pip install ".[gui,cookie]"gui：弹窗扫码登录用的 Playwright（装完执行一次 playwright install chromium）
cookie：可选的“从本地浏览器 cookie 库提取登录态”备选路径
安装后得到命令行入口 sjtu-pan-mcp。
交大云盘用 jAccount 登录。本工具不接触你的账号密码——运行：
sjtu-pan-mcp login会发生这些事：
自动弹出一个浏览器窗口，打开交大云盘登录页并自动跳到 jAccount 统一身份认证页
你用交我办 App 或微信扫码（也可以账号密码登录）
登录态被自动抓取并校验，写入配置文件，窗口自动关闭
也可以让 agent 代劳：对 agent 说“登录交大云盘”，它会调用 pan_login 工具，同样弹窗，并阻塞等待你扫码完成。
如果弹窗登录不可用（比如无桌面环境），用手动兜底：浏览器登录 pan.sjtu.edu.cn 后，F12 → 应用程序/Application → Cookies → https://pan.sjtu.edu.cn → 复制 USER_TOKEN 的值，写入配置文件（见下一步）的 user_token 字段。
sjtu-pan-mcp status输出账户、组织和空间列表即成功。登录态默认存放在：
~/.sjtu-pan-mcp/config.json # Windows: C:\Users\<你>\.sjtu-pan-mcp\config.json完整配置示例（仓库里的 config.example.json）：
{
"user_token": "登录后自动写入；也可手动粘贴 USER_TOKEN cookie 值",
"default_download_dir": "~/Downloads/sjtu-pan",
"organization_id": 0,
"allowed_url_hosts": [
"pan.sjtu.edu.cn",
".sjtu.edu.cn",
".myqcloud.com",
".qcloud.com"
]
}配置项 | 说明 |
| 登录态（必填）。 |
| 默认下载目录，不填则为 |
| 固定组织（多组织账号用，0 = 自动选择） |
| 出站请求主机白名单（安全加固，见下） |
也可以用环境变量（优先级高于配置文件）：
环境变量 | 作用 |
| 直接传登录态 |
| 指定配置文件路径 |
| 指定配置目录 |
在客户端的 MCP 配置里加一个 stdio 服务器（以安装后的可执行文件路径为准）：
{
"mcpServers": {
"sjtu-pan": {
"command": "sjtu-pan-mcp",
"args": [],
"env": {}
}
}
}Windows 上如果 sjtu-pan-mcp 不在 PATH，写成完整路径，例如：
{
"mcpServers": {
"sjtu-pan": {
"command": "C:\\Users\\<你>\\AppData\\Local\\Programs\\Python\\Python313\\Scripts\\sjtu-pan-mcp.exe",
"args": [],
"env": {}
}
}
}登录态在 ~/.sjtu-pan-mcp/config.json 里全局共享，多个客户端无需分别登录。配置好后重启客户端，对 agent 说“看看我交大云盘里有什么”即可。
登录态有效期取决于登录时是否勾选“记住登录态”（约 10 天，否则约 2 小时）。过期时任何工具会返回 InvalidUserToken，重新跑一次 sjtu-pan-mcp login 或让 agent 调 pan_login 扫码即可。
所有出站请求仅允许 http/https，且目标主机必须在白名单内（默认 pan.sjtu.edu.cn、.sjtu.edu.cn 及其 S3 存储域名）
请求前校验主机名及其解析 IP，拒绝 localhost、环回、私有、链路本地、保留和多播地址——防止 SSRF 打到内网
重定向逐跳重新校验；远程文件名会做净化（剥离路径分隔符、NTFS ADS、保留设备名），且本地落盘路径被限制在目标目录内
本项目不存储、不上传任何账号密码；配置文件中只有会话 token，config.json 已被 .gitignore 排除
“看看我交大云盘个人空间根目录有什么” → pan_list_dir
“把 /论文/2026 整个目录下载到 D:\pan-download” → pan_download_dir
“搜一下云盘里叫 paper 的文件” → pan_search
“下载 /论文/2026/paper.pdf 到桌面” → pan_download_file
项目结构：src/sjtu_pan_mcp/（client.py 两层 API 客户端、login.py 弹窗登录、auth.py 登录态解析、security.py URL 校验、server.py MCP 工具）
测试：python smoke_test.py（本地逻辑 + 有 token 时的真实列目录/下载）、python smoke_mcp.py（MCP 协议握手）、python test_gui_login_e2e.py（弹窗登录全链路，注入 cookie 模拟扫码）
已知细节：文件下载是 302 到预签名 S3 URL，跟随重定向时不能携带原 query 参数否则签名失效；user_id 参数仅用于流量统计
接口响应字段未公开文档，客户端对 JSON 形状做了容错解析；如交大云盘改版，优先改 client.py 里的归一化函数
Mccount666 — 项目作者
Claude — AI 辅助开发
交大云盘账户信息与登录态自检（用户ID、组织、空间列表）
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does indicate the tool reports account information and login state and names the output categories, which implies a read-only inspection. However, it does not disclose what happens when the user is not logged in, whether any session is created or refreshed, or what error/edge behavior to expect.
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 line with the main purpose front-loaded and the specific fields in parentheses. It is economical and readable, though it is a telegraphic noun phrase rather than a full imperative sentence, and 自检 is slightly jargon-like.
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, low-complexity tool with no output schema, the description covers the core purpose and basic return categories. It is not fully complete because it lacks authentication-edge behavior and does not clarify whether the space list is identical to the output of pan_list_spaces, and no usage alternatives are given.
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 coverage is 100%, so the schema fully describes the call signature. Per the baseline for zero-parameter tools, no parameter documentation is needed from the description.
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 identifies the resource (交大云盘账户/cloud-drive account) and the action (登录态自检/login-state self-check), and enumerates returned fields: user ID, organization, and space list. It is distinguishable from siblings like pan_login and pan_list_spaces because it is account-centric, though the term 自检 is slightly ambiguous and could be read as a health check rather than a data 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?
No guidance is given about when to use pan_account versus its siblings. The description does not mention that pan_login is for establishing a session, that pan_list_spaces is for space listing alone, or any conditions that should route an agent to one tool over another.
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 |
|---|---|---|---|
| space | No | 空间名或 space_id，省略则用个人空间 | |
| local_dir | No | 本地目标目录，省略则用默认下载目录 | |
| max_files | No | 最多下载多少个文件（默认100，上限500） | |
| remote_dir | 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 disclosure burden. It does disclose recursive behavior and subdirectory preservation, which is useful, but it omits other relevant traits such as whether local files are overwritten, authentication requirements, or behavior when max_files is reached.
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 says exactly what the tool does and preserves the most important behavioral detail in a parenthetical. There is no filler or repetition of schema 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?
The description plus fully documented schema is minimally viable for invoking the tool, but gaps remain: no output schema or return-value description, no detail on what happens when max_files is exceeded, and no statement about local-dir creation or overwrite behavior. It is adequate but not rich enough for fully confident autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all four parameters. The description adds no parameter-level detail beyond the concept of the remote directory, which is already captured in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('recursively download the entire directory') and adds the key scoping detail that subdirectory structure is preserved. This clearly distinguishes it from sibling pan_download_file, which is for single files.
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 makes the use case clear: use it when you need a whole directory downloaded recursively. It does not explicitly name alternatives or exclusions, but the strong directory-vs-file contrast with siblings like pan_download_file provides clear context without needing elaboration.
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 |
|---|---|---|---|
| space | No | 空间名或 space_id，省略则用个人空间 | |
| local_dir | No | 本地目标目录，省略则用默认下载目录 | |
| remote_path | Yes | 云盘文件路径，如 /论文/2026/paper.pdf |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. The description only says it downloads a file; it doesn't disclose what happens if the file doesn't exist, whether it overwrites existing files, whether the download is synchronous or async, or any permission/authentication requirements. For a tool that writes to local disk, this is a significant transparency gap.
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, concise sentence that front-loads the action and target. There's no waste, though it lacks useful behavioral details. It is appropriately sized for a simple tool, but could earn a 5 with more complete usage context.
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 download tool that writes to the local filesystem, the description is minimal. It doesn't specify behavior on missing files, overwrite policies, default download directory location, or what feedback the agent receives on success/failure. With no output schema and no annotations, the description should carry more operational 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?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds the context that remote_path is for a single file, and local_dir is a local target, but doesn't add much beyond the schema descriptions. Since coverage is high, 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?
The description states a specific verb (download) and resource (single file on 交大云盘) with a target (local directory). It clearly distinguishes from siblings like pan_download_dir, which handles directories. However, it doesn't explicitly name the sibling or the scope distinction beyond the phrase '单个文件'.
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 usage for single-file downloads, and the sibling context shows pan_download_dir exists for directory downloads, but the description doesn't explicitly state when to use this tool vs pan_download_dir or mention alternatives. It provides no exclusion criteria or condition-based guidance.
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 |
|---|---|---|---|
| path | Yes | 文件或目录路径 | |
| space | No | 空间名或 space_id，省略则用个人空间 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden: '查看/view' unambiguously signals a read-only metadata operation, and the examples disclose what the result will contain (size, modification time). It does not mention auth requirements or error behavior, but those are not critical for this simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact Chinese sentence conveys the tool, target, scope, and example output with no filler. The key qualifier 'single' is front-loaded before the metadata examples.
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 two-parameter read-only tool, the description combines with a fully documented schema to give an agent what it needs to call the tool. It lacks only explicit guidance on when to reach for a listing/search sibling instead, which is a minor gap given the clear 'single item' qualifier.
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 the schema already documents path and space. The description adds the notion of a single file/directory and what 'info' means, but it does not elaborate on path syntax or space resolution beyond the schema, matching the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (查看/view) and resource (单个文件/目录的元信息), with concrete examples of the metadata returned (size, modification time). The 'single item' qualifier clearly separates it from sibling tools like pan_list_dir, which lists a directory's contents, and pan_download_file, which retrieves file data.
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 use case—inspect metadata for one path—but never states when to prefer this tool over pan_list_dir or pan_search, and gives no exclusions or prerequisites. An agent can infer the purpose but not a routing rule.
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 |
|---|---|---|---|
| path | No | 目录路径，如 / 或 /论文/2026 | / |
| space | No | 空间名或 space_id，省略则用个人空间 |
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 reveals that the tool performs a read-only listing of a directory, but does not mention authentication requirements, default-space behavior, pagination, hidden files, or sort order. This is minimally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler. The action verb '列出' leads, and the object is precisely stated. 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?
For a simple directory-listing tool, the description gives the basic operation and the schema covers parameters, but there is no guidance on return format, required authentication state, or when to choose this over sibling tools. With no output schema and no annotations, this leaves meaningful 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%, so the schema already documents path and space, including defaults and examples. The description adds little beyond restating that the operation targets a directory, which matches the path parameter. Baseline 3 is appropriate since the schema carries the parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('list') and resource ('files and subdirectories under a directory of the SJTU cloud drive'), making the core purpose clear. It does not explicitly differentiate itself from siblings like pan_list_spaces or pan_file_info, but the resource scope is concrete enough to avoid major ambiguity.
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 given about when to use this tool versus alternatives such as pan_search, pan_list_spaces, or pan_download_dir. The description merely states what it does; an agent must infer that listing a known directory is the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出交大云盘的全部空间（个人空间/团队空间），含 space_id
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有 annotations，描述承担了全部行为披露责任。它说明了工具会列出空间并包含 space_id，但未说明是否需要先登录、返回结果是否仅限于当前用户有权限访问的空间，以及“全部空间”是否存在分页或数量限制。行为主体清楚，但边界条件有缺失。
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?
单句描述，动词开头，信息密度高；既说明了对象范围（个人空间/团队空间），又给出了关键输出字段 space_id，没有冗余内容。
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?
对于一个无参数、无输出 schema 的简单列表工具，描述基本够用，但未说明登录前提和访问范围边界，可能导致代理在未登录或权限受限时对返回结果产生错误预期。整体可用但存在轻微信息缺口。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
参数数量为 0，输入 schema 为空且描述覆盖率达到 100%，因此参数层面没有额外信息需要补充。描述中提到的 space_id 是输出信息而非参数，不影响参数语义评分。
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?
描述以具体动词“列出”明确行为，资源是“交大云盘的全部空间”，并进一步限定“个人空间/团队空间”以及返回包含 space_id。与 pan_list_dir、pan_search 等兄弟工具在资源对象上有明显区分，代理能清楚知道该工具用于枚举空间而非目录或文件。
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?
描述隐含了“需要获取空间列表或 space_id 时使用”的用途，但未显式说明何时不使用、是否有前置条件（如登录），也没有点名可替代的兄弟工具。属于可以通过上下文推断的使用场景，但缺少明确排除或替代指引。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
弹出浏览器窗口登录交大云盘（jAccount 扫码/账号密码），登录成功后自动保存登录态。调用后会阻塞等待用户完成登录
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No | 等待登录的超时秒数（默认 240） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: it pops up a browser window, blocks until the user completes login, and automatically saves the login state. Since no annotations are provided, this description carries the full burden of behavioral disclosure. However, it does not mention what happens on timeout or failure, which is a minor gap.
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 concise and front-loaded: it states the primary action first, then the blocking behavior and state saving. It is a single sentence with no redundant information, efficiently conveying the essential facts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior and parameter, but it does not explicitly state that this tool should be invoked before other pan_* operations to establish authentication. It also does not mention what happens after successful login (e.g., return values), but since there is no output schema, that is acceptable. The missing prerequisite guidance is a notable gap for an agent deciding tool order.
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 only parameter, timeout, is fully described in the input schema (default 240 seconds). The tool description does not add any additional information about the parameter beyond what the schema already provides. With schema coverage at 100%, 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 states the tool's purpose: it opens a browser window to log in to the SJTU cloud drive via jAccount (QR code or account/password) and saves the login state. It uses a specific verb ('登录') and names the resource ('交大云盘'), making it distinguishable from sibling tools like pan_download_dir or pan_list_dir.
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 explains what the tool does but does not explicitly state when to use it relative to the sibling tools. It does not mention that this is a prerequisite for other pan_* operations, nor does it discuss any alternatives or conditions where this tool should or should not be used. The context is implied but not stated.
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 |
|---|---|---|---|
| space | No | 限定空间（名或 space_id），可省略 | |
| keyword | Yes | 搜索关键词 |
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 burden. '搜索' implies a non-mutating operation and '全局' mentions scope, but the description omits whether login is required, how results are returned, and any cross-space behavior details. The agent is left to infer important invocation 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 redundant words: it names scope, operation, object, and criterion efficiently. Every word contributes to tool selection and invocation.
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 two-parameter search tool, the schema handles parameter meaning and the description handles overall purpose and scope. However, with no output schema and no annotations, the description does not state the return format or any prerequisite such as prior login, leaving a noticeable but non-fatal 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 coverage is 100%, with both 'keyword' and 'space' already documented. The description only restates keyword-based search and adds no format, syntax, or semantic detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('搜索'/'search'), a resource ('文件'/'files'), and a clear global scope ('全局'), with the key criterion ('按关键词'). This distinguishes it cleanly from sibling listing, file-info, and download 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?
'全局搜索' clearly conveys the intended use case: find files across the drive by keyword rather than browsing an individual directory or space. However, it does not explicitly name alternatives or say when not to use the tool.
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.
v0.1.0pan_accountpan_download_dirpan_download_filepan_file_infopan_list_dirpan_list_spacespan_loginpan_searchScored across 8 tools
每个工具都有明确用途：下载目录 vs 下载文件、列出空间 vs 列出目录、搜索 vs 文件信息等，没有任何重叠或混淆。登录与账户检查也区分清晰。
所有工具以 pan_ 前缀开头，但动词模式不一致：有 pan_download_dir/file 和 pan_list_spaces/dir 使用动词+名词，而 pan_search、pan_account、pan_login、pan_file_info 则混合了纯动词和名词形式，缺乏统一模式。
8个工具对于一个云盘访问服务器来说是合理的，覆盖了登录、账户、列表、搜索、下载等核心操作，既不过多也不显单薄。
明显缺少上传、删除、创建目录、重命名等写入操作，整个工具集仅限于读取和下载。对于云盘服务，这是一个显著缺口，可能导致用户无法完成完整工作流。
Persistent file storage for AI agents via MCP and curl. Upload, download, and version files.
Securely search and manage workspace context files for AI agents and teams.
Artifact store for AI agents — read, write, and search files by path; share by rendered URL.
PDF, image, video, OCR, screenshot, SQL, QR and text tools for agents. No API key, no signup.
