This server lets you administer a Dockerized Nextcloud instance via OCC commands through MCP.
Get Nextcloud system status (get_status)
List trusted domains (get_trusted_domains)
Add trusted domains (add_trusted_domain)
Optimize the database (optimize_db) — adds missing indices, columns, primary keys, and converts filecache bigint
Export Deck boards for a user (export_deck)
Run arbitrary OCC commands (run_occ), with full administrative control and potentially destructive side effects
Manage and administer a Nextcloud instance via OCC commands, including running arbitrary OCC commands, checking status, managing trusted domains, and optimizing the database.
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 Control Plane MCP Server check the health of my Nextcloud instance"
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.
module_type: mcp-server
status: active
protocol: mcp
primary_capability: nextcloud-administration
requires: docker, python>=3.10
works_with: nextcloud
last_verified: 2026-08-30Status: Active | Last Verified Date: 2026-08-30
Provides a Model Context Protocol (MCP) server for managing and administering Nextcloud instances via dockerized OCC commands.
What it does: Provides an MCP server that securely interfaces with a local Dockerized Nextcloud deployment via OCC (php occ) commands. It allows AI agents to retrieve Nextcloud system status, view/manage trusted domains, perform database optimizations, export Deck Kanban data, and execute arbitrary OCC commands.
What it does not do: It does not run Nextcloud itself; it only controls a running Nextcloud Docker container (default: nextcloud_app_1). It interfaces via Docker Exec, not over HTTP via Nextcloud's Provisioning API.
Related MCP server: Nextcloud MCP Server
Agents can use this to administer, configure, troubleshoot, and maintain a Nextcloud instance without requiring SSH access or manual GUI interaction, fully automating tasks like adding trusted domains when network topology changes, optimizing the database after upgrades, or exporting Deck boards.
Language: Python 3.10+
Protocol: Model Context Protocol (FastMCP)
Integrations: Executes commands against the local Docker daemon via asyncio.create_subprocess_exec.
Dependencies: mcp>=1.0.0, local Docker CLI.
Linux, macOS, or any host with a functional Docker CLI.
Compatible with any MCP client (Claude Desktop, Antigravity).
Designed for Nextcloud containers running with the www-data user.
pip install -e .
nextcloud-mcp-controlHealth Check: Once connected via an MCP client, call the get_status tool to verify successful OCC communication with the container.
Variable | Description | Default |
| Target Nextcloud Docker container name |
|
No other external environment variables are required beyond the host's standard Docker configuration.
Tool/API | Description | Side Effects |
| Gets Nextcloud system status via | None: Read-only operation. |
| Lists configured trusted domains in Nextcloud. | None: Read-only operation. |
| Adds a new trusted domain to Nextcloud configuration. | Modifies State: Updates |
| Runs missing indices, missing columns, missing primary keys, and filecache bigint conversions. | Modifies State: Alters database schema and indices. |
| Exports Nextcloud Deck boards and cards for a specific user via | None: Read-only operation. |
| Executes arbitrary OCC command inside the Nextcloud container. | Variable: Depending on the specific OCC command invoked. |
Trust Boundary: The server assumes the host running it has authorization to execute docker exec against the configured Nextcloud container. The MCP server runs with the same permissions as the user executing it.
Security Risks: The run_occ tool allows executing arbitrary administrative commands against the Nextcloud instance, which could be destructive (e.g., occ maintenance:install, occ app:disable, etc.). Agents with access to this MCP server have full administrative control over the Nextcloud container.
Design Philosophy & Upstream Reconciliation: This repository is a specialized, security-hardened reference implementation for TheNovaNodes ecosystem. Unlike some generic or upstream production Docker images (e.g., ghcr.io/cbcoutinho/...) which may blindly expose 90+ tools, this Control Plane intentionally exposes only a strictly minimized subset of critical tools. This deliberate reduction in the attack surface prevents autonomous agents from unintentionally triggering destructive commands, while still preserving manual execution capability via run_occ if explicitly required. (Fixes #3)
Run the test suite using pytest:
pytestOperations & Logs: Logs are output to standard error via Python's logging module.
Backup/Restore: Since this server is stateless and interfaces with Nextcloud, standard Nextcloud backup procedures apply (database dump and file backup). No state is stored within the MCP server itself.
Rollback: To rollback changes made by add_trusted_domain, use run_occ to manually config:system:delete trusted_domains <index>.
Add this to your mcp_config.json or claude_desktop_config.json:
{
"mcpServers": {
"nextcloud-control": {
"command": "python",
"args": ["-m", "nextcloud_mcp_control.server"]
}
}
}Operates on a single Nextcloud container per server instance (configurable via NC_CONTAINER_NAME).
Part of the TheNovaNodes and Antigravity Agent Ecosystem.
Refer to the repository license for details.
Adds a new trusted domain to Nextcloud config. First checks current trusted domains to assign the next available index.
Args: domain: Domain name or IP address to add (e.g. 'cloud.example.com' or '192.168.1.100')
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a non-obvious behavior: 'First checks current trusted domains to assign the next available index.' This goes beyond a simple statement of purpose. However, it does not mention potential error conditions or side effects like config reload, but with no annotations, this is a reasonable burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing only three sentences. It front-loads the purpose, then adds the index-assignment behavior, and ends with a dedicated Args section. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description covers purpose, behavior, and parameter semantics. The presence of an output schema makes it unnecessary to describe return values. It could be improved by mentioning when to use this versus get_trusted_domains, but that is not critical.
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 only provides a string parameter with no description. The description adds meaning by specifying 'Domain name or IP address' and giving examples ('cloud.example.com' or '192.168.1.100'), which clarifies the accepted format.
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 'Adds a new trusted domain to Nextcloud config' with a specific verb and resource. It distinguishes from sibling tools like get_trusted_domains by using 'add' rather than 'get'.
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 intended use is clear from the description, but it does not explicitly mention alternatives or exclusions. It does not say when to prefer this over get_trusted_domains, though the verb 'add' makes the primary use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the Nextcloud system status via OCC status --output=json.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose side effects. It uses the read-oriented verb 'gets' and specifies a status command, which implies a non-destructive operation, but it does not explicitly state safety, permissions, or potential error conditions. This leaves some ambiguity but not contradictory information.
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, information-dense sentence that states the purpose and the exact command. Every word is useful and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema available, the description adequately explains what the tool does and how it works. It could mention prerequisites like OCC availability, but that is not critical for this simple status check. Overall, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially high. The description adds no parameter details, which is acceptable. Per the guidelines, zero parameters earn a baseline score of 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 'Gets the Nextcloud system status' and specifies the exact command 'OCC status --output=json'. This is a specific verb+resource that distinguishes it from sibling tools like get_trusted_domains or the generic run_occ.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage (checking system status) but does not explicitly state when to prefer this tool over alternatives or when not to use it. There is no mention of exclusions or comparison with the generic run_occ tool, so it relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists configured trusted domains in Nextcloud via OCC config:system:get trusted_domains.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. The verb 'Lists' implies a read-only operation, but the description does not explicitly state side-effect-freedom, permission requirements, or return behavior. It adds the underlying OCC command as context, which is helpful but 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?
One concise sentence with no filler. It includes the OCC command as a value-add without extra verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument listing tool with an existing output schema, the description is sufficiently complete. It explains what it does and how (via OCC), and there are no hidden parameters or side-effect concerns for the agent to worry about.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered. The description provides no parameter details, but none are needed. Baseline for 0 params 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 uses the specific verb 'Lists' with the resource 'configured trusted domains in Nextcloud' and names the exact OCC command, making the tool's purpose unambiguous and distinguishing it from siblings like add_trusted_domain.
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 is given about when to use this tool versus alternatives like run_occ. The usage is implied by the name and description (when you need to see trusted domains), but there are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs database optimization commands on Nextcloud:
db:add-missing-indices
db:add-missing-columns
db:add-missing-primary-keys
db:convert-filecache-bigint
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It lists the exact commands executed, which is useful, but it does not disclose potential side effects, required permissions, or performance impacts. It provides moderate transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with a single sentence followed by a clear bulleted list of commands. Every element adds value with no waste.
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 simplicity (no parameters) and the presence of an output schema, the description is largely complete. It could mention prerequisites or outcomes, but the command list provides sufficient context for basic 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 tool has zero parameters, and the schema coverage is 100%. Per the rule, 0 parameters gives a baseline of 4. No parameter information is needed or missing.
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 runs database optimization commands on Nextcloud and enumerates four specific commands. This is a specific verb+resource and distinguishes it from generic siblings like run_occ.
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?
It implies the tool is for the listed commands but does not explicitly state when to use it over alternatives like run_occ, nor does it mention when not to use it. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes arbitrary OCC command inside the Nextcloud container (nextcloud-app).
Args: command: The occ command string, e.g. "status --output=json" or "app:list"
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 fails to warn that arbitrary OCC commands can have destructive side effects or require elevated permissions, and it does not mention any safety precautions. The only added context is the container name, which is insufficient for such a powerful execution tool.
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 extremely concise, front-loaded with the main purpose in the first sentence, and the parameter explanation is compact. Every sentence contributes value without redundancy, making it an efficient reference for an agent.
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?
Despite having an output schema, the description lacks crucial context for a generic command execution tool: no mention of error handling, exit codes, output format, or the potential for irreversible actions. The guardrails and usage constraints are absent, leaving the agent underinformed for a tool that can execute arbitrary privileged commands.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no per-property description (0% schema coverage), but the description compensates by explaining the 'command' parameter as an occ command string with concrete examples like 'status --output=json' and 'app:list'. This adds meaningful syntax guidance beyond the bare schema field.
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 executes arbitrary OCC commands inside the Nextcloud container, with examples showing command format. It distinguishes itself from specialized sibling tools like get_status or optimize_db by emphasizing 'arbitrary' commands, making it the generic entry point.
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?
Usage guidance is implied by the word 'arbitrary', suggesting it can be used for any OCC command not covered by specialized tools, but it does not explicitly state when to prefer this over its siblings or when not to use it. No alternatives are mentioned, so the guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_trusted_domainget_statusget_trusted_domainsoptimize_dbrun_occEach tool has a clear and distinct role: run_occ is a generic executor, while get_status, get_trusted_domains, add_trusted_domain, and optimize_db are specific conveniences. Although run_occ can technically perform the others' tasks, the descriptions make the boundaries clear and no two tools appear interchangeable.
All tools follow a consistent snake_case verb_noun pattern (run_occ, get_status, get_trusted_domains, add_trusted_domain, optimize_db). The verbs clearly indicate the action and the nouns the target, making the naming predictable and uniform.
With 5 tools, the server is well-scoped for a focused Nextcloud control plane. Each tool serves a distinct administrative purpose, and the count is neither too sparse nor excessive for the stated domain.
The presence of run_occ ensures full coverage of all possible occ commands, so there are no missing operations for the domain. The specific wrappers cover common tasks like status, trusted domains, and DB optimization, and any other need can be fulfilled via run_occ.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage CloudPepper servers, Odoo instances, backups, and deployments over MCP.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Deploy and manage web apps on InstaPods: create pods, push files, run commands, read logs.
Deploy, monitor, and manage your OpenClaw AI assistants via natural language.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TheNovaNodes/nextcloud-mcp-control'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
