Provides tools for managing NextCloud files (list, upload, download, delete, move, copy, search, versioning) and sharing (create public links, user/group shares, list, delete).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nextcloud-mcp-server list files in my Documents folder"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
๏ปฟ
A professional Model Context Protocol (MCP) server for seamless NextCloud integration
Empower your AI agents with comprehensive NextCloud file management and sharing capabilities
Installation โข Quick Start โข Features โข Documentation โข Security
๐ File Management | ๐ Sharing | ๐ Security | ๐ ๏ธ Developer Experience |
List, upload, download | Public links | App passwords | Full TypeScript support |
Create directories | User/group shares | Environment variables | Comprehensive tests |
Delete files/folders | Password protection | Secure authentication | Professional documentation |
Move and rename | Expiration dates | HTTPS enforcement | Easy integration |
๐ฏ 14 Comprehensive Tools - Complete file operations and sharing management
๐ Enhanced Security - Built-in app password support and best practices
๐๏ธ Professional Architecture - TypeScript-first with full type safety
๐ Rich Documentation - Detailed guides and examples
๐ WebDAV Integration - Native NextCloud protocol support
โก High Performance - Optimized for speed and reliability
๐ Universal Compatibility - Works with any NextCloud instance
Related MCP server: Nextcloud MCP Server
# Install globally for CLI usage
npm install -g nextcloud-mcp-server
# Or install locally in your project
npm install nextcloud-mcp-servergit clone https://github.com/abdullahMASHUK/nextcloud-mcp-server.git
cd nextcloud-mcp-server
npm install
npm run buildFor enhanced security, create a dedicated app password:
Navigate to NextCloud Settings
NextCloud โ Settings โ Security โ App passwordsCreate New App Password
Enter name: MCP Server
Click "Create new app password"
Copy the generated password: xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
Why App Passwords?
โ Limited scope and permissions
โ Can be revoked independently
โ No access to your main account
โ Auditable access logs
# Copy the environment template
cp .env.example .envEdit your .env file:
NEXTCLOUD_URL=https://your-nextcloud-server.com
NEXTCLOUD_USERNAME=your-username
NEXTCLOUD_PASSWORD=your-app-password-here # Use app password!Add to your claude_desktop_config.json:
{
"mcpServers": {
"nextcloud": {
"command": "nextcloud-mcp-server",
"env": {
"NEXTCLOUD_URL": "https://your-nextcloud-server.com",
"NEXTCLOUD_USERNAME": "your-username",
"NEXTCLOUD_PASSWORD": "your-app-password"
}
}
}
}# Run the MCP server
nextcloud-mcp-server
# Or with Node.js
node build/index.js{
"name": "list-files",
"arguments": {
"path": "/Documents"
}
}Response: Returns array of files with metadata (name, size, type, modification date)
{
"name": "upload-file",
"arguments": {
"remotePath": "/documents/report.pdf",
"content": "JVBERi0xLjQK..." // base64 encoded content
}
}{
"name": "move-file",
"arguments": {
"sourcePath": "/old-location/document.pdf",
"destinationPath": "/new-location/document.pdf",
"overwrite": false
}
}Response: Confirmation message with source and destination paths
{
"name": "copy-file",
"arguments": {
"sourcePath": "/Documents/template.docx",
"destinationPath": "/Projects/new-document.docx",
"overwrite": true
}
}Response: Confirmation message with copy operation details
{
"name": "search-files",
"arguments": {
"query": "quarterly report",
"path": "/Documents",
"limit": 20,
"type": "file"
}
}Response: Array of matching files with full metadata
Type Options: file, directory, all
{
"name": "get-file-versions",
"arguments": {
"path": "/Documents/important-document.pdf"
}
}Response: Array of file versions with timestamps, sizes, and user information
{
"name": "restore-file-version",
"arguments": {
"path": "/Documents/important-document.pdf",
"versionId": "1672531200"
}
}Response: Confirmation of version restoration
{
"name": "create-share",
"arguments": {
"path": "/Documents/presentation.pptx",
"shareType": 3,
"password": "secure123",
"expireDate": "2024-12-31",
"note": "Shared for team review"
}
}Share Types:
0 - User share
1 - Group share
3 - Public link
4 - Email share
# Clone and install
git clone https://github.com/abdullahMASHUK/nextcloud-mcp-server.git
cd nextcloud-mcp-server
npm install
# Development commands
npm run dev # Run with auto-reload
npm run build # Build TypeScript
npm run test # Run test suite
npm run lint # Check code quality
npm run format # Format codeProject Structure:
src/
โโโ index.ts # Main MCP server
โโโ services/
โ โโโ nextcloud.ts # NextCloud API client
โโโ types.ts # TypeScript definitions
โโโ utils/ # Utility functions
__tests__/ # Test suites
build/ # Compiled outputโ Do | โ Don't |
Use app passwords | Use main account password |
Store in environment variables | Hardcode credentials |
Use HTTPS URLs | Use HTTP connections |
Rotate passwords regularly | Keep old passwords |
Monitor access logs | Ignore security events |
๐ App Password Integration - Dedicated authentication tokens
๐ HTTPS Enforcement - Secure connections required
๐ Environment Variables - Safe credential storage
๐ Error Handling - No credential exposure in logs
๐ก๏ธ Permission Scoping - Limited access rights
App password created and configured
HTTPS enabled on NextCloud server
Environment variables properly set
.env file added to .gitignore
Regular password rotation scheduled
MIT License - see LICENSE file for details.
๐ด Fork the repository
๐ฟ Create your feature branch
git checkout -b feature/amazing-feature๐ป Make your changes
โ Add tests for new features
๐งช Run the test suite
npm run test
npm run lint๐ Commit your changes
git commit -m "โจ Add amazing feature"๐ Push to your branch
git push origin feature/amazing-feature๐ Open a Pull Request
If this project helped you, please consider giving it a โญ on GitHub!
๐ Documentation
๐ Report Issues
๐ฌ Discussions
๐ง Contact Maintainer
MIT License ยฉ 2024 Abdullah MASHUK
Permission is hereby granted, free of charge, to any person obtaining a copy of this software...
๐จ Beautified README with professional formatting and visual enhancements
๐ Added interactive tables, badges, and collapsible sections
๐ค Updated author information and git configuration
๐ Enhanced navigation with emojis and better organization
โจ Improved user experience for npm and GitHub viewers
โจ Enhanced documentation and README
๐ Added comprehensive security guidelines
๐ Improved TypeScript definitions
๐ Bug fixes and stability improvements
๐ Updated documentation
๐ง Configuration improvements
๐ ๏ธ Build process optimization
๐ Initial release
๐ Basic file operations (list, upload, download, delete)
๐ Share management (create, list, delete)
๐ง TypeScript implementation
โ Comprehensive test coverage
๐ Full documentation
Made with โค๏ธ by Abdullah MASHUK
Building bridges between NextCloud and AI assistants ๐
Copy a file or directory in NextCloud
| Name | Required | Description | Default |
|---|---|---|---|
| sourcePath | Yes | Path of the file or directory to copy | |
| destinationPath | Yes | Destination path for the copy | |
| overwrite | No | Whether to overwrite if destination exists |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as whether directory copies are recursive, the effect of the overwrite flag, or any permission requirements. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. Every word is necessary to convey the basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is insufficient. It does not explain important aspects like recursive copy behavior, conflict handling, or return values, which leaves the agent with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters. However, the tool description adds no additional meaning beyond what the schema already provides, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Copy'), the resource ('file or directory'), and the context ('NextCloud'). It is a specific verb+resource pair that distinguishes it from sibling tools like move-file or delete-file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as move-file (which would move instead of copy) or other file operations. The description lacks context on use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new directory in NextCloud
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path of the directory to create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is minimal. It does not disclose whether the operation creates intermediate directories, what happens if the directory already exists, or any permission requirements. The description carries full burden but adds little behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the tool's purpose. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description is adequate but not complete. It lacks details on behavior regarding parent directories, error states, and return value. It serves as a minimal viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. The schema already documents the 'path' parameter with a description. Since schema coverage is 100%, baseline is 3. No extra context is provided about path format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a new directory in NextCloud'. It uses a specific verb ('create') and resource ('directory'), and it is clearly distinguishable from sibling tools which handle files and shares.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., parent directory must exist) or scenarios where other tools (e.g., upload-file) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a file or directory from NextCloud
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path of the file or directory to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as whether deletion is permanent, if a recycle bin exists, or required permissions. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks the depth needed to fully inform an agent. It is front-loaded but insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple with one parameter and no output schema, the description could be adequate with annotations. However, without any behavioral transparency or usage guidance, it is incomplete for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the 'path' parameter. The tool description does not add new semantic information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a file or directory from NextCloud', specifying both the action and the resource. This distinguishes it from sibling tools like copy-file or move-file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like move-file (which might also remove the source). The description lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a file from NextCloud
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path of the file to download |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose any behavioral traits (e.g., read-only operation, auth requirements, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Could be improved by adding usage guidelines, but very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple download tool with one parameter, description is minimally complete but lacks behavioral context. Could reference output format or permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no extra meaning beyond schema; path parameter is adequately described in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Download' and resource 'file from NextCloud', distinguishing it from sibling tools like upload-file, delete-file, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Missing context on prerequisites or recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get version history of a file
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path of the file to get versions for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the purpose without disclosing output format, pagination, or other behavioral traits. The agent cannot infer what the version history contains (e.g., timestamps, authors).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently states the purpose. It is appropriately short but could be slightly expanded without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain the return value (e.g., list of version metadata). It is incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single parameter (path) fully (100% coverage). The tool description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and the resource (version history of a file). It is specific and uses a verb+resource format that distinguishes it from siblings like restore-file-version or download-file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like restore-file-version or search-files. There is no mention of context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and directories in NextCloud
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to list (default: /) | / |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It lacks details such as whether listing is recursive, how many results it returns, error handling (e.g., invalid path), or authentication requirements. This leaves the agent with insufficient information about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is efficient and front-loaded. It earns its place but could be slightly longer to include missing context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description should explain the return format (e.g., list of file names, full paths). It fails to address this, leaving the agent without a complete picture of the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter documented). The description adds no information beyond the schema's own description of the 'path' parameter. Baseline score of 3 applies since the schema already provides adequate semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (files and directories in NextCloud), distinguishing it from sibling tools like copy-file or delete-file. However, it does not specify what the list returns (e.g., names, paths, metadata), which would enhance clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like search-files or list-shares. For a listing tool, it should indicate when to use it over search, or mention that it lists only top-level contents if no recursion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move or rename a file or directory in NextCloud
| Name | Required | Description | Default |
|---|---|---|---|
| sourcePath | Yes | Current path of the file or directory | |
| destinationPath | Yes | New path where the file or directory should be moved | |
| overwrite | No | Whether to overwrite if destination exists |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action. It does not disclose whether the operation is destructive (original removed), requires specific permissions, or how the overwrite parameter behaves beyond what the schema implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is appropriately sized for a straightforward file operation, though it could include more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (3 params, mutation, no output schema), the description is adequate but has gaps: it does not explain behavior on overwrite, relationship to rename, or mention any side effects like overwriting existing files.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the parameter names and schema descriptions, e.g., it does not explain that rename is achieved by changing the filename in destinationPath.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Move or rename a file or directory in NextCloud' uses a specific verb ('Move or rename') and resource ('file or directory'), clearly distinguishing it from siblings like copy-file, delete-file, and create-directory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., copy-file for duplication) or any prerequisites. No when-to-use or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore a specific version of a file
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path of the file to restore | |
| versionId | Yes | ID of the version to restore |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like whether the operation is destructive, if a new version is created, or required permissions. The agent gains no insight 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words or repetition, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action with two parameters and no output schema, the description provides the essential purpose but lacks behavioral details or usage context. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Restore a specific version of a file' clearly indicates the action (restore) and the resource (a specific version of a file), effectively distinguishing it from sibling tools like 'get-file-versions' and 'download-file'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description offers no context about prerequisites, such as needing to list versions first with 'get-file-versions', or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for files and directories by name or content
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| path | No | Directory path to search within (optional) | |
| limit | No | Maximum number of results to return | |
| type | No | Type of items to search for | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It does not disclose whether the search is recursive, how content search works (full-text or metadata), or the nature of the operation (presumably read-only). This omission is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with appropriate front-loading, containing no extraneous words. While more detail could be added, brevity is not a flaw here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, no annotations), the description is too minimal. It omits search behavior, result format, and any behavioral constraints, leaving significant gaps for an agent to understand how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters adequately. The description adds no additional meaning beyond the schema's parameter descriptions, providing no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as searching for files and directories by name or content, using a specific verb and resource, and it distinguishes from sibling tools like list-files (which likely lists without search) and operations like copy or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusions. It simply states the function without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test connection to NextCloud server
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits beyond the name. It merely states 'test connection' without explaining what happens (e.g., does it return a boolean, throw errors, or modify state?). Insufficient detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a single sentence with no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally adequate for a simple connection test, but it omits what the output represents (e.g., success/failure). With no output schema, the description should clarify the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, so schema coverage is 100%. The description adds no parameter information, but none is needed. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Test') and the resource ('connection to NextCloud server'). It is specific and not a tautology, distinguishing it from sibling tools that perform file or share operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a file to NextCloud
| Name | Required | Description | Default |
|---|---|---|---|
| remotePath | Yes | Remote path where to upload the file | |
| content | Yes | Base64 encoded file content |
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 a generic upload. It omits critical details like whether existing files are overwritten, size limits, or side effects, providing insufficient transparency for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks necessary details. It could be more informative without adding length, such as mentioning base64 encoding or overwrite behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a write operation with two parameters and no output schema, the description is incomplete. It fails to mention success responses, error conditions, or usage context, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (remotePath and content). The description adds no extra meaning beyond the schema, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload') and resource ('a file to NextCloud'), making the tool's purpose unambiguous. It is distinct from sibling tools like copy-file or download-file, though it lacks specificity about the upload mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like copy-file or move-file. The description offers no context for selection or prerequisites, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.1.0copy-filecreate-directorycreate-sharedelete-filedelete-sharedownload-fileget-file-versionslist-fileslist-sharesmove-filerestore-file-versionsearch-filestest-connectionupload-fileEach tool has a clearly distinct purpose: file operations are separate from sharing, versioning, and connection testing. No two tools overlap in function.
All tool names follow a consistent verb-noun pattern with hyphens (e.g., copy-file, create-share). No mixing of conventions.
14 tools is well-scoped for a NextCloud file management server, covering essential operations without being overwhelming.
The tool surface covers core CRUD for files, versioning, and sharing. Minor gap: no update-share tool, but sharing is typically create/delete only.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent file storage for AI agents via MCP and curl. Upload, download, and version files.
Browse and manage files in your Moxt AI workspace from any MCP client.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yoโฆ
Securely search and manage workspace context files for AI agents and teams.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/abdullahMASHUK/nextcloud-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
