360 AI Cloud Drive MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes focused on specific file operations (e.g., list, move, rename, search, share, upload, download, create folder), with clear boundaries. However, there is some overlap between 'file-download-stdio' and 'get-download-url', as both handle download links, which could cause minor confusion in selection.
Naming Consistency4/5
The naming follows a consistent pattern of verb-noun with hyphens (e.g., file-list, file-move, file-rename), which is predictable and readable. The only deviation is 'user-info', which uses a noun-verb structure instead, but this is a minor inconsistency that doesn't significantly impact usability.
Tool Count5/5
With 11 tools, the count is well-scoped for a cloud drive server, covering essential file management operations (CRUD, search, share, user info). Each tool serves a clear purpose, and there are no redundant or missing tools that would make the set feel too thin or bloated.
Completeness5/5
The tool set provides comprehensive coverage for cloud drive operations, including full CRUD (create via upload/save, read via list/search, update via move/rename, delete implied by move/overwrite), file sharing, downloading, and user management. There are no obvious gaps that would hinder an agent from performing typical file management tasks.
Average 3.1/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('rename') but doesn't disclose behavioral traits like whether it requires specific permissions, if it overwrites existing items with the new name, what happens on failure (e.g., if src_name doesn't exist), or if it's idempotent. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without any fluff. It's front-loaded and appropriately sized for a simple rename operation, with every word contributing to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks information on behavioral aspects (e.g., error handling, permissions), output format (what is returned on success/failure), and usage context compared to siblings. This is inadequate for a tool that modifies data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters (src_name as original path, new_name as new name without parent path). The description adds no additional meaning beyond the schema, such as explaining path conventions or constraints (e.g., special characters allowed). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('重命名' meaning 'rename') and the resource ('云盘中的文件或文件夹' meaning 'files or folders in cloud storage'). It distinguishes from siblings like file-move (which likely moves files) and file-save (which likely saves content), but doesn't explicitly differentiate from tools like make-dir (which creates directories) in terms of when to use rename vs create new.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't mention when to use file-rename versus file-move (which might handle path changes) or make-dir (for creating new folders with different names). There's no context about prerequisites, such as needing existing files/folders to rename.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the action ('保存' - save) implying creation/write, but doesn't disclose permissions needed, rate limits, file size constraints, overwrite behavior, or response format. For a write operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that efficiently communicates the core functionality. Every word earns its place: it specifies the action, two input methods, and destination. No wasted words or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with 3 parameters and no annotations or output schema, the description is insufficient. It doesn't explain what happens on success/failure, file naming conventions, format restrictions beyond 'md格式', or how conflicts are resolved. The agent lacks crucial information to use this tool effectively in production scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing good parameter documentation. The description adds marginal value by mentioning the two input methods (URL or text content) and that content should be in markdown format, but doesn't elaborate beyond what's in the schema descriptions. With high schema coverage, the baseline 3 is appropriate as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('保存文件' - save file) and target resource ('到云盘' - to cloud drive), specifying two input methods (URL or text content). It distinguishes from siblings like file-download-stdio (download) and file-upload-stdio (upload via stdio), though not explicitly. However, it doesn't fully differentiate from all siblings like file-move or file-rename, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose URL vs content input, or how this differs from sibling tools like file-upload-stdio or file-download-stdio. There are no prerequisites, exclusions, or context for selection among the many file-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool returns detailed file information for matching results, which is useful, but it lacks critical details such as whether this is a read-only operation (implied by '搜索' but not stated), any rate limits, authentication requirements, error handling, or the format of the returned information. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core functionality in a single sentence. It efficiently covers the key aspects (searching, filtering, pagination, and return details) without unnecessary words. However, it could be slightly improved by structuring it into clearer clauses, but overall it earns its place with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format (e.g., what '详细信息' includes), error conditions, or how results are ordered. Without annotations to cover behavioral traits, the description should provide more context to help the agent use the tool effectively, but it falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantic value beyond the input schema, which has 100% coverage. It mentions '根据关键词搜索' (search by keyword) and '按文件类型筛选和分页查询' (filter by file type and pagination query), but these are already covered in the schema descriptions for 'key', 'file_category', 'page', and 'page_size'. With high schema coverage, the baseline is 3, as the description doesn't provide additional context like examples or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for files and folders in cloud storage using keywords, with filtering by file type and pagination. It specifies the verb '搜索' (search) and resource '文件和文件夹' (files and folders), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'file-list' or 'get-download-url', which is why it doesn't reach a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'file-list' (which might list files without searching) or 'get-download-url' (which retrieves download links). It mentions support for filtering and pagination, but this is more about functionality than usage context, leaving the agent with no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it states the tool generates sharing links and supports batch processing, it doesn't describe important behavioral aspects: what permissions are required, whether links are public or private, expiration settings, rate limits, or what the output looks like. For a tool that creates shareable links (potentially sensitive operation), this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - two sentences that directly state the tool's function and its batch capability. Every word earns its place with zero redundancy. The structure is front-loaded with the primary purpose followed by an important capability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a file-sharing tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the sharing links look like, their properties (expiration, permissions), error conditions, or how results are returned for batch operations. For a tool that creates potentially sensitive sharing links, more context about the operation's behavior and output is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'paths' fully documented in the schema. The description adds minimal value beyond the schema - it mentions batch processing ('支持批量生成多个文件的分享链接') which aligns with the schema's pipe-separated format, but doesn't provide additional semantic context about path formats, validation rules, or edge cases. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '生成云盘文件的分享链接' (generate sharing links for cloud drive files). It specifies the verb (generate) and resource (cloud drive file sharing links), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get-download-url' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions batch processing capability ('支持批量生成多个文件的分享链接'), but doesn't clarify when to use this versus single-file sharing methods or how it differs from 'get-download-url'. No exclusions, prerequisites, or context for tool selection are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does (gets download links) but doesn't describe important behaviors: whether links are temporary or permanent, authentication requirements, rate limits, error responses, or what format the links are in. This leaves significant gaps for an agent to understand how to use the tool effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly address the tool's purpose and parameter options. No wasted words or unnecessary information. However, it could be slightly more front-loaded by mentioning the parameter options in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that retrieves download links with no annotations and no output schema, the description is incomplete. It doesn't explain what the output looks like (URL format, expiration, etc.), error conditions, or how this differs from similar sibling tools. The agent would need to guess about important behavioral aspects of this operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters completely. The description adds minimal value beyond the schema by mentioning the two parameter options exist ('可以通过文件NID或路径获取'), but doesn't provide additional context about when to choose one over the other or any parameter constraints not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取云盘中文件的下载链接' (get download links for files in cloud storage). It specifies the verb (获取/get) and resource (下载链接/download links for files), but doesn't explicitly differentiate from sibling tools like 'file-download-stdio' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: it mentions two alternative parameters (nid or fpath) but doesn't explain when to use this tool versus alternatives like 'file-download-stdio' or 'file-share'. No context about prerequisites, error conditions, or when-not-to-use scenarios is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While '创建新文件夹' implies a write operation, it doesn't address permissions needed, whether it overwrites existing folders, error conditions, or what happens on success/failure. The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core function and key capability. It's appropriately brief and front-loaded with the main action. No wasted words, though it could be slightly more informative about behavioral aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, permissions required, or how it interacts with existing files/folders. Given the complexity of a folder creation operation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'fname' with its type, description, and example. The description adds no additional parameter information beyond what's in the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('创建新文件夹' - create new folder) and resource ('在云盘中' - in cloud storage), making the purpose immediately understandable. It doesn't specifically distinguish from siblings like 'file-move' or 'file-rename', but the core function is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when not to use it, or how it differs from other file operations like 'file-save' or 'file-upload-stdio' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the core functionality (getting download links and supporting direct downloads) and some behavioral aspects (default directory, permission requirements). However, it lacks important behavioral details such as: whether this is a read-only or write operation, what happens when 'auto' is false versus true, error conditions, rate limits, authentication requirements, or what the output looks like (especially critical since there's no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that efficiently convey the core functionality and key behavioral aspects. It's front-loaded with the primary purpose, followed by configuration details. There's minimal redundancy, though some information overlaps with the schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a file download operation with 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (critical without output schema), doesn't describe error conditions, doesn't clarify the relationship between getting download links versus direct downloading, and provides minimal behavioral context for a tool that presumably performs file system operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters. The description adds minimal value beyond the schema: it mentions the default download directory (.mcp-downloads) which is already in the schema's 'downloadDir' description, and reinforces that 'auto' controls direct downloading. No additional parameter semantics, constraints, or usage examples are provided beyond what's in the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取云盘中指定文件的下载链接并支持直接下载文件' (get download links for specified files in cloud storage and support direct file downloads). It specifies the verb ('获取' - get/obtain) and resource ('云盘中指定文件' - specified files in cloud storage), but doesn't explicitly distinguish it from sibling tools like 'get-download-url' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context by mentioning default behavior (default download to .mcp-downloads folder) and prerequisites (download directory must have read/write permissions). However, it doesn't explicitly state when to use this tool versus alternatives like 'get-download-url' or 'file-save', nor does it provide exclusion criteria or comparative guidance with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it retrieves user details but doesn't specify what details are included, whether it requires authentication, rate limits, or error conditions. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and no output schema, the description is incomplete. It doesn't explain what user details are returned, the format of the response, or any behavioral aspects like authentication needs. For a tool that likely involves sensitive user data, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage (since there are no parameters). The description doesn't need to add parameter details, so it meets the baseline of 4 for tools with no parameters, as it doesn't have to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('获取' meaning 'get' or 'retrieve') and resource ('360AI云盘用户详细信息' meaning '360AI cloud disk user detailed information'), providing a specific purpose. However, it doesn't differentiate from sibling tools like 'file-list' or 'file-search' which might also involve user information indirectly, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions batch support but lacks critical behavioral details: whether it overwrites existing files, requires specific permissions, handles errors, or provides confirmation. For a mutation tool, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core purpose and batch support. Zero wasted words, efficiently conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., overwrite behavior, error handling), return values, or integration with sibling tools. The high schema coverage doesn't compensate for missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly (src_name with format example, new_name with target folder). The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('移动' meaning 'move') and resource ('云盘中的文件或文件夹' meaning 'files or folders in cloud storage'), specifying it supports batch operations ('批量移动多个文件'). It distinguishes from siblings like file-rename (renaming within same location) and file-save (saving new content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for moving files/folders within cloud storage, but does not explicitly state when to use this vs. alternatives like file-rename (for renaming) or file-save (for creating/saving). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it's a read operation (获取列表), supports pagination (分页查询), and returns detailed metadata (文件名、大小、创建时间、修改时间等). However, it doesn't mention potential limitations like rate limits, authentication requirements, or error conditions. The description adds value but lacks comprehensive behavioral context for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and key features (pagination, return details). Every part earns its place: the first clause states the action, the second adds pagination support, and the third specifies return values. There is no wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic completeness for a read-only list tool. It covers the purpose, pagination behavior, and return details, but lacks information on error handling, authentication, or output structure. For a tool with 3 parameters and no structured output definition, this is adequate but leaves gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (page, page_size, path) well-documented in the schema. The description adds minimal semantic context by mentioning '指定路径' (specified path) and '分页查询' (pagination query), which aligns with the parameters but doesn't provide additional meaning beyond what the schema already covers. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取云盘指定路径下的文件和文件夹列表' (get file and folder list from cloud drive at specified path). It specifies the verb (获取/获取列表) and resource (云盘指定路径下的文件和文件夹), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like file-search, which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through '指定路径' (specified path) and '分页查询' (pagination query), suggesting this is for browsing directory contents rather than searching. However, it doesn't explicitly state when to use this versus alternatives like file-search (which might search across directories) or provide any exclusion criteria. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions support for batch uploads, which is useful, but lacks critical behavioral details such as authentication requirements, file size limits, overwrite behavior, error handling, or rate limits. For a mutation tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste: the first states the core functionality, and the second adds the batch capability. It is front-loaded and appropriately sized for the tool's complexity, making it easy to grasp quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and involves mutation (uploading files), the description is incomplete. It lacks details on return values, error conditions, side effects, or security considerations. For a file upload tool with such complexity, the description should provide more context to guide safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value by confirming the upload path is for the cloud drive, but does not provide additional semantics beyond what the schema states. With high schema coverage, the baseline is 3, but the description slightly enhances understanding, warranting a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('upload'), the resource ('local files'), and the destination ('to cloud drive specified path'). It distinguishes from siblings like file-download-stdio (download) and file-move (move within cloud), making the purpose specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for uploading local files to cloud storage, but does not explicitly state when to use this tool versus alternatives like file-save (which might save content directly) or file-share (which shares existing cloud files). No exclusions or prerequisites are mentioned, leaving some ambiguity about appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![ecs_mcp_server MCP server](https://glama.ai/mcp/servers/Qihoo360/ecs_mcp_server/badges/card.svg)](https://glama.ai/mcp/servers/Qihoo360/ecs_mcp_server)

Score Badge

Copy to your README.md:

[![ecs_mcp_server MCP server](https://glama.ai/mcp/servers/Qihoo360/ecs_mcp_server/badges/score.svg)](https://glama.ai/mcp/servers/Qihoo360/ecs_mcp_server)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Qihoo360/ecs_mcp_server'

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