nutstore-mcp

by silverze

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation5/5
Each tool targets a distinct operation: listing vs searching vs info vs existence; text vs binary I/O; single vs batch operations. Potential overlaps like list_files vs get_directory_tree or create_directory vs mkdirs are clarified by descriptions.
Naming Consistency3/5
Most tools follow a verb_noun pattern (list_files, upload_file, delete_file), but some diverge: 'exists' and 'is_dir' are bare predicates, 'mkdirs' is Unix-style, and 'batch_delete' uses an adverb prefix. The inconsistency is noticeable but not chaotic.
Tool Count3/5
With 19 tools, the set is on the heavy side for a file management server. Although each tool serves a specific purpose, some consolidation is possible (e.g., merge create_directory/mkdirs or handle batch in delete_file), pushing it beyond the typical well-scoped range.
Completeness5/5
The set covers the full lifecycle: create (mkdirs, write_file_content, upload_file), read (list_files, search_files, download_file), update (copy_file, move_file), and delete (delete_file, batch_delete), plus connectivity and info checks. No obvious gaps exist.
Average 3.4/5 across 19 of 19 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only says it copies files or directories. It misses critical details such as overwrite behavior, recursive copying for directories, permission needs, or side effects, leaving the agent underinformed about the tool's actual 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 a single short sentence, making it highly concise and front-loaded with the core action (copy files or directories). It avoids unnecessary words, though it sacrifices informative detail.
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 supports both files and directories with no annotations, the description is incomplete. It fails to address key operational nuances like recursive copy for directories, conflict resolution, or return behavior. The presence of an output schema does not fill the gaps in usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for both required parameters (src_path, dst_path). The description does not explain their meaning, format, or constraints, failing to compensate for the low schema coverage. Parameter names alone are insufficient, as the description adds no semantic value beyond what the schema already implies.
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 that the tool copies files or directories in Nutstore, specifying the verb and resource. It distinguishes from siblings like move_file by implying a copy operation, though it does not explicitly differentiate from alternatives.
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 vs alternatives like move_file, upload_file, or download_file. The description lacks context about appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'create new directory' with no information about overwrite behavior, error handling, permissions, or effects on existing directories. This is insufficient for safe operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose. It is front-loaded and contains no unnecessary words or information.
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 simplicity, the description is minimal but incomplete: it lacks usage context, parameter clarification, and differentiation from mkdirs. Since an output schema exists, not describing return values is acceptable, but the missing usage and parameter semantics make the description insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'path' with no description, and the description does not explain its meaning, format, or expectations. With 0% schema description coverage, the description fails to compensate, leaving the parameter semantics entirely unclear.
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) and resource (a directory in Nutstore). It distinguishes from file operations like list_files or write_file_content, but does not differentiate from its sibling mkdirs, which may also create directories.
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 like mkdirs. There is no mention of scenarios, preconditions, or exclusions, leaving the agent without context for tool selection.
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 disclosing behavioral traits. It only states 'get directory tree structure' without revealing specifics like recursion behavior, handling of hidden files, or that it is a read-only operation. The simplicity implies a safe read, but crucial behavioral details are omitted, so it earns a 2.
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, clear sentence with no redundant words. It is front-loaded and to the point, making it easy to parse. For a tool with this level of simplicity, the length is appropriate and every word is necessary.
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?
While the tool has an output schema (which explains return values), the description omits crucial operational details such as how 'path' should be formatted, what 'max_depth' controls, and whether the result is recursive. The presence of an output schema does not compensate for the lack of behavioral context, so the description is incomplete for effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not mention the 'path' or 'max_depth' parameters at all. It fails to compensate for the lack of parameter documentation, leaving the agent to infer meaning only from parameter names and defaults. This is a significant gap, so it scores a 1.
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 '获取坚果云目录树结构' translates to 'Get Nutstore directory tree structure', which clearly states a specific verb ('get') and resource ('directory tree'). It distinguishes itself from siblings like list_files by emphasizing the hierarchical 'tree' structure, though it doesn't explicitly name alternatives. This is clear but lacks explicit sibling differentiation, warranting a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like list_files or get_file_info. The description simply states what it does without providing context on ideal use cases, such as 'use for recursive exploration' or 'avoid if you only need a flat listing'. This absence of usage direction results in a score of 2.
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. It only says 'get detailed info' but does not disclose the read-only nature, error behavior for nonexistent paths, permissions required, or what specific details are returned. This is a significant gap for a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no filler. It is concise and to the point, though it is so minimal that it risks under-specification rather than conciseness.
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 simple tool (1 param, output schema exists), the description still fails to provide enough context for correct tool selection and invocation. It lacks guidance on when to use this vs. siblings and does not clarify path construction or return expectations beyond what the output schema already covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage) and the tool description does not explain the 'path' parameter beyond implying it is the file/directory path. The format (absolute vs relative), encoding, or example value is missing, leaving invocation ambiguous.
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 retrieves detailed information for a file or directory. It distinguishes from sibling tools like read_file_content (which reads content) and list_files (which lists entries), though it does not explicitly contrast with exists or is_dir.
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 usage context is provided. The description does not indicate when to choose this tool over alternatives such as exists or get_directory_tree, nor does it specify any prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states the operation. It omits critical details such as side effects (source removal), overwrite behavior, path handling, permissions, or error conditions. The description adds no value beyond the basic definition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately communicates the core function. There is no fluff or redundant wording, making it highly efficient for an agent 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?
Even with an output schema present, the description omits essential context for a mutation tool: destination-collision behavior, atomicity, error cases, and whether metadata is preserved. The lack of annotations and minimal description leaves significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no explanation of src_path and dst_path semantics. It doesn't clarify path formats, whether paths are relative or absolute, or any operational behaviors tied to each parameter, leaving the agent to guess from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves or renames files/directories in Nutstore, using specific verbs and a resource type. This distinguishes it from sibling tools like copy_file and delete_file, making its purpose 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 like copy_file or delete_file. There are no usage scenarios, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name and operation type.
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 must stand alone. It does not disclose whether the tool returns a boolean, throws an error on non-existence, or how it handles different path types. This is a significant gap for a check tool.
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, concise sentence that front-loads the action. It is appropriately sized for a simple tool, though it sacrifices detail for brevity.
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 the simplicity of the tool and presence of an output schema, the description is minimally adequate. However, it lacks context about path semantics, typical use cases, or relationship to sibling tools, making it incomplete for a fully self-sufficient agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description has 0% schema coverage and does not explain the required 'path' parameter beyond the word 'file or directory'. It omits important details like path format (absolute/relative), accepted URL patterns, or edge case behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb '检查' (check) and resource '文件或目录' (file/directory), clearly stating it verifies existence. This distinguishes it from sibling tools like list_files (which lists) or is_dir (which checks directory type).
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 get_file_info or is_dir. It only states the basic function, leaving the agent to infer appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states the basic action without mentioning recursion behavior, path semantics, matching rules, or result format. This is a significant gap for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is appropriately front-loaded and every word earns its place.
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?
Despite having an output schema, the description lacks essential context such as parameter semantics, default behaviors, and usage scenarios. For a tool with three parameters and no annotations, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implicitly covers the keyword parameter but says nothing about path or recursive. With 0% schema description coverage, the agent has to infer the meaning of these parameters from defaults and names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a keyword-based search for files in Nutstore, using a specific verb ('search') and resource ('files'). It distinctly differentiates from sibling tools like list_files and get_directory_tree.
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 list_files or get_directory_tree. No context about appropriate use cases, prerequisites, or limitations is given.
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?
There are no annotations, so the description must disclose behavior. It only mentions deletion and provides a caution, but it does not state whether deletion is permanent, if it supports recursive deletion for directories, whether files go to a recycle bin, or what permissions are required. This is a significant gap for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately communicates the action and the target, with a useful caution. Every word earns its place, and the structure is clean and front-loaded.
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 destructive operation with no annotations and minimal schema information, the description is insufficient. It lacks essential details about deletion semantics, path handling, and consequences, leaving the agent without enough context to invoke the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'path' parameter with no description (0% coverage). The tool description adds that the path refers to a file or directory in Nutstore, but does not clarify path format, absolute vs. relative paths, or any constraints. Given the low schema coverage, the description fails to compensate adequately.
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 'delete' and the target resource 'files or directories in Nutstore', making the tool's purpose unmistakable. It distinguishes itself from siblings like list, search, and read, and the caution flag reinforces that this is a destructive operation.
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 given on when to use this tool versus alternatives such as batch_delete or move_file. The caution 'use with caution' is a general warning but does not provide specific decision-making context or exclusion criteria.
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?
Annotations are absent, so the description bears full responsibility. It reveals only that the tool creates directories recursively, but does not mention error handling, idempotency, permission requirements, or behavior when directories already exist. This lack of behavioral context 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 a single concise sentence with no filler, front-loading the key behavior. It is appropriately sized for a simple tool.
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?
Despite its simplicity, the description leaves critical gaps: no path semantics, no error behavior, and no differentiation from the sibling create_directory tool. The presence of an output schema does not compensate for these missing details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema contains a single 'path' parameter with no description (0% coverage). The description does not specify the expected format, absolute vs relative, or any constraints for the path. It only indirectly indicates that path refers to the directory to create, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool recursively creates multi-level directories in Nutstore, using a specific verb ('create') and resource ('multi-level directories'). The terms 'recursively' and 'multi-level' distinguish it from sibling tools like create_directory, which likely creates a single directory.
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 creating nested directories but provides no explicit guidance on when to use this tool versus alternatives like create_directory, nor any exclusions. Usage context is implied by the phrase 'multi-level' but not explicitly stated.
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 must disclose behavioral details on its own. It adds one useful prerequisite (local_path must already exist), but it does not mention what happens when the file does not exist, whether remote_path is a file path or directory, whether uploads overwrite existing files, or any permission or response behavior. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main operation. It uses two clear sentences, provides a practical example, and contains no fluff. Every sentence contributes value, making it an appropriate and efficient description.
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 with no annotations and an output schema (but no parameter descriptions), the description should cover the essential usage context. It omits remote_path semantics, which is critical for correct invocation. While the output schema may explain return values, the description lacks enough context about how to properly perform a single-file upload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains local_path with a clear example, but remote_path is not described at all. This leaves a required parameter semantically ambiguous, so the description only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '将本机单个文件上传到坚果云' (upload a single local file to Jianguo Cloud). It specifies the verb (upload), resource (local file), and destination (cloud), and distinguishes it from sibling tools like upload_dir by explicitly limiting to a single file.
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 single-file uploads and notes that local_path must be an existing file, but it does not explicitly state when to use this tool versus alternatives like upload_dir or how it differs from download tools. There are no clear exclusions or alternative recommendations, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core behavior but does not specify behavior for nonexistent paths, error handling, or whether symbolic links are followed. The description is clear but lacks edge-case context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words or repetition. It is front-loaded and directly states the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple predicate tool with an output schema, the description is adequate but not fully complete. It lacks edge-case behavior (e.g., nonexistent paths) and does not clarify when to use this tool over 'exists' or 'get_file_info'. The description would benefit from stating the exact return behavior and error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'path' without adding details about format (absolute/relative, URL-encoding), required conventions, or how invalid paths are handled. The description provides minimal extra meaning beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '判断坚果云路径是否为目录' clearly states the tool's purpose: to determine whether a given Jianguoyun path is a directory. It uses a specific verb and resource, and it distinguishes itself from sibling tools like 'exists' (which checks only existence) and 'get_file_info' (which retrieves details).
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 when you need to know if a path is a directory, but it provides no explicit when-to-use guidance or alternatives. There are no exclusions or comparisons to sibling tools such as 'exists' or 'get_file_info', so the user must infer the appropriate context.
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 mentions the comma-separated input format but does not disclose whether deletion is permanent, recursive, or what happens if a path does not exist. For a destructive tool, this lack of warning 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 a single sentence, front-loaded with the action and object, and includes the essential input format in a concise parenthetical. Every word contributes to understanding the tool's purpose and parameter format, with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and parameter format, and an output schema exists so return values need not be explained. However, for a destructive tool with no annotations, it lacks behavioral context such as irreversibility or error behavior. The low parameter count and simple structure mitigate the incompleteness, but additional safety notes would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'paths' as a string, with no description. The tool description compensates by explaining that paths are comma-separated and can refer to files or directories. This adds crucial meaning beyond the schema, though it does not provide details like path format or relative/absolute resolution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: batch deleting files/directories in Nutstore. The verb 'delete' and resource 'files/directories' are specific, and the phrase 'batch' distinguishes it from the sibling tool 'delete_file'. The parenthetical about comma-separated paths adds further clarity.
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 batch aspect of the tool implies its use case: when multiple paths need to be deleted at once. However, the description does not explicitly state when to use this tool versus alternatives like 'delete_file', nor does it mention any prerequisites or constraints. Guidance is implied but not fully articulated.
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 only states the purpose and does not mention whether the tool is read-only, what happens on failure, or whether authentication is required. For a connection check, this lack of detail leaves the agent uncertain about side effects.
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, short, front-loaded sentence that states exactly what the tool does without any filler. Every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters) and the presence of an output schema, the description is sufficient for basic selection and invocation. It could be improved with usage context and behavioral details, but those are covered in other dimensions. The core purpose is fully conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no constraints requiring explanation. The description adds no parameter details, but with no parameters, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'check' and clearly identifies the resource as 'connection status with Nutstore WebDAV'. This distinguishes it from sibling file-operation tools, which all focus on file system actions.
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 verifying connectivity before performing file operations, but does not explicitly state when to use it or mention any alternatives. The context of sibling tools suggests a pre-flight check, but no direct guidance is given.
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 transparency burden. It states the core behavior (list files/subdirectories) but does not disclose details such as path validation, hidden-file behavior, sorting, or error handling. For a read-only listing tool this is minimally acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the full purpose without redundancy or filler. It is appropriately minimal for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter and an output schema, the description is largely complete. It defines scope (files/subdirectories in a directory) and context (Nutstore), but could add a note about immediate vs recursive listing or path handling to fully cover edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one 'path' parameter with 0% description coverage. The description's '指定目录' clarifies that the path parameter refers to a directory, adding some meaning beyond the schema's type/default. However, it does not explain path format, accepted values, or interaction with the default '/'.
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 ('列出' / list) and the resource ('指定目录下的文件和子目录' / files and subdirectories in a specified directory) for Nutstore. It effectively distinguishes listing from sibling tools like search_files (searching) or get_directory_tree (tree view).
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 the tool is for listing immediate files and subdirectories under a path, but it does not explicitly mention when to prefer it over alternatives like get_directory_tree or search_files. No exclusions or sibling references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose key behaviors: recursion, preserving directory structure, and requiring an existing local directory. However, it omits other relevant traits such as overwrite behavior, authentication needs, or handling of nested files/failures, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that provides the core action and the only meaningful parameter clarification. Every word earns its place, with no redundant filler.
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 the tool's moderate complexity (recursive upload with two parameters) and no annotations, the description covers the essential purpose but leaves gaps around remote_dir semantics and runtime behavior. The presence of an output schema reduces the need to explain return values, but the description is not fully complete for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only clarifies one parameter: local_dir ('existing local directory path'). The remote_dir parameter is left entirely unexplained beyond its name, and the description does not compensate for the missing schema documentation. This leaves ambiguity about the destination path semantics.
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 entire local directory recursively') and the target resource ('to Nutstore'), and distinguishes itself from sibling tools like upload_file by focusing on directories and recursive behavior. It also notes preserving directory structure, which is a specific, identifiable purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to upload a whole local directory recursively. It does not explicitly mention exclusions or alternatives, but the wording and sibling context (e.g., upload_file for files) make the usage context unambiguous.
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 must carry the burden. It discloses the target as local_path and mentions format support, but does not mention overwrite behavior, directory creation, or other side effects.
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?
Three concise sentences with a clear purpose statement and an example. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple download operation with two parameters and an output schema. It covers purpose and one parameter, but lacks explicit notes on overwriting or directory creation.
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 0%, so the description must compensate. It explains local_path clearly, but remote_path is only implied. This is partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('download a single file from Nutstore to a local path'), specifies scope ('single file'), and distinguishes from sibling tools like download_dir. It also clarifies format support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this is for single-file downloads (not directories), which differentiates it from download_dir. However, it does not explicitly mention alternatives or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the recursive behavior, directory structure preservation, and auto-creation of local_dir. However, it omits important traits like overwrite behavior, error handling, or authentication requirements, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the core purpose and then explaining a parameter. No unnecessary words, making it easy to quickly understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema, the description covers the essential context: remote source, local destination, recursive scope, and directory creation behavior. It doesn't address edge cases like existing files, but the tool's simplicity means this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly explains local_dir's meaning and auto-creation, while remote_dir is inferable from the tool's purpose. This provides meaningful semantic guidance beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recursively downloads an entire directory from Nutstore to a local path, preserving directory structure. This specifies the action, resource, and scope, distinguishing it from file-level downloads and uploads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it's for whole-directory recursive downloads, with local_dir auto-created. It doesn't explicitly mention alternatives or when not to use it, but the context is clear enough to guide appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses key behaviors: returns text, supports only text file types, excludes binary files, and suggests an alternative for large files. It does not mention error handling or authentication, but the core behavioral traits are covered.
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 three concise sentences, each adding essential information: function, file type constraints, and large-file alternative. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, a single parameter, and the presence of an output schema, the description provides sufficient context. It covers the key use-case, limitations, and alternative tool, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description does not explain the remote_path parameter at all. Although the parameter name is somewhat self-explanatory, the description does not compensate for the lack of schema documentation, leaving path format or semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads Nutstore text file content and returns text for AI processing. It explicitly distinguishes itself from siblings by limiting to text files and directing large files to download_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: use for text files only, not binary files, and use download_file instead for large files. This clearly communicates when to use the tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden of behavioral disclosure. It reveals that the tool creates or overwrites files (a potentially destructive action) and restricts usage to text content. It does not mention permissions, atomicity, or error handling, but the core side-effects and limitation are clearly stated.
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 sentences, front-loaded with the primary action, followed by a constraint and a pointer to an alternative tool. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward file write operation with a simple schema and an output schema, the description covers the essential aspects: purpose, overwrite behavior, text-only constraint, and binary alternative. It lacks details on error conditions or directory creation, but these are not critical for a basic write tool and the sibling context plus output schema fill the remaining gaps.
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 input schema has zero description coverage, so the description must compensate. It implicitly identifies 'content' as text and 'remote_path' as the target file location, but provides no further details such as encoding, path format, or size limits. The parameter names are self-explanatory, but the description adds only minimal semantic enrichment.
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 ('写入' - write) and resource ('坚果云文件' - Nutstore file), and specifies the action creates or overwrites. It also distinguishes itself from the sibling upload_file for binary content, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this tool is for text content and instructs users to use upload_file for binary files. This provides a clear when-to-use and when-not-to-use directive, effectively distinguishing it from alternatives 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.

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:

[![nutstore-mcp MCP server](https://glama.ai/mcp/servers/silverze/nutstore-mcp/badges/card.svg)](https://glama.ai/mcp/servers/silverze/nutstore-mcp)

Score Badge

Copy to your README.md:

[![nutstore-mcp MCP server](https://glama.ai/mcp/servers/silverze/nutstore-mcp/badges/score.svg)](https://glama.ai/mcp/servers/silverze/nutstore-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/silverze/nutstore-mcp'

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