Provide the MCP server as a dedicated exApp

[Simon-Spettmann]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Feature request

Which Nextcloud Version are you currently using: 34.0.0.12

Is your feature request related to a problem? Please describe.

It is my understanding that nextcloud/context_agent has extensive dependencies and apparently needs an AI provider itself to work. This is something I neither need nor want to integrate with my Nextcloud instance. For someone who just wants the MCP endpoint, this a lot of extra "baggage".

Describe the solution you'd like

I would prefer to have a dedicated and simple exApp with just the MCP server, nothing more, nothing less. The MCP endpoint of this MCP server could be used by both external AI agents as well as the internal AI agent of nextcloud/context_agent (as an "external" service).

Describe alternatives you've considered

I tried to use nextcloud/context_agent without these dependencies, or at least with all dependencies except an AI provider, but couldn't get it to work. I also considered cbcoutinho/nextcloud-mcp-server, but this seems to be an external service that connects to the Nextcloud instances and bridges MCP calls to API endpoints. I would rather have an official, integrated and minimal MCP server solution.

Additional context

My (possibly naive) proposal would be to refractor ex_app/lib/mcp_server.py and Nextcloud-specific tools from ex_app/lib/all_tools to a dedicated exApp. We might also take this chance to (re)implement the MCP server based on the official modelcontextprotocol/python-sdk.

[Simon-Spettmann]

A dedicated MCP server based on the official modelcontextprotocol/python-sdk would also help solve:

• Nextcloud MCP-Server an OAuth #74
• Home Assistant Compatibility #103

[cbcoutinho]

Maintainer of cbcoutinho/nextcloud-mcp-server here — this issue is essentially the use case the project was built for, so let me share why a separate server exists and why I think a native, in-core MCP endpoint is unlikely.

Why a standalone server, decoupled from any AI provider

nextcloud-mcp-server is deliberately just the MCP endpoint — it bridges MCP calls to Nextcloud's existing APIs (Notes, Calendar, Contacts, Tables, WebDAV, Deck, Cookbook, …) and carries no AI-provider dependency of its own. That's exactly the "just the MCP server, none of the extra baggage" split you're describing. The client (Claude Desktop, an internal agent, whatever) brings the model; the server only exposes tools.

The semantic search + vector-DB layer this project also offers is a strictly optional add-on — the server runs fully without it, exposing all the CRUD tools over plain Nextcloud APIs with zero embeddings, no vector store, and no provider configured. If you do opt in, the RAG/answer features use MCP sampling so the client's model does the generation; the server itself ships no API keys. So you can run it as a pure, minimal MCP bridge and never touch any AI dependency at all.

Why native MCP in Nextcloud core (PHP) is unlikely

The MCP transport is built around long-lived, streaming connections (SSE / Streamable HTTP) and an async request lifecycle. Nextcloud's core runs on PHP under php-fpm with a synchronous, request-per-process model — short-lived requests, no persistent event loop — which doesn't fit a protocol-compliant streaming MCP server. This isn't really a "missing feature" so much as an architectural mismatch. Notably, it's the same reason context_agent itself isn't implemented in the PHP core but ships as a Python exApp via AppAPI: the moment you need a compliant MCP server you're effectively pushed into a separate async service anyway. So whether it lives in context_agent's exApp or a dedicated one, it's a separate process either way.

What this project already provides for your scenario

Both transports the spec defines are supported:

• Local stdio — for personal/desktop use (run it alongside your client).
• Streamable HTTP server — for teams/shared deployments, with OAuth via Nextcloud Login Flow v2 (per-user app passwords, application-level scope enforcement), so each user authenticates as themselves against any Nextcloud 16+ instance with no special server-side apps required.

That last mode is, I think, what you're really after for "teams that want the MCP endpoint": an integrated, multi-user, auth'd MCP server with no model/provider coupling.

So to the core of the request: Nextcloud-via-PHP can't realistically be a protocol-compliant MCP server, and that's precisely why both context_agent and nextcloud-mcp-server exist as separate apps rather than core features. A minimal, provider-free exApp like you're proposing is a reasonable thing to want — and it already exists today as nextcloud-mcp-server; whether something equivalent should live under the Nextcloud org is really the open question here.

[Simon-Spettmann]

@cbcoutinho Thank you very much for the quick and extensive response.

I understand why and agree with you that a separated server is necessary. That is why I recommended moving to a dedicated exApp (via AppAPI) based on modelcontextprotocol/python-sdk, not an implementation in nextcloud/core based on modelcontextprotocol/php-sdk.

As for the "semantic search + vector-DB", I haven't familiarized myself with that, but from what I understand it seems like a very good addition to having just an MCP server.

A minimal, provider-free exApp like you're proposing is a reasonable thing to want — and it already exists today as nextcloud-mcp-server; whether something equivalent should live under the Nextcloud org is really the open question here.

In part yes, but I was looking for two (more) things: First, a (simple) installation via the Nextcloud Server App store, and second, something live under or at least vetted by the Nextcloud org.

---

As a general note, thanks to you and all the contributors of cbcoutinho/nextcloud-mcp-server. I didn't intend to "downplay" or make all your work redundant. For the most part I just wanted to jump start the discussion of an "official" MCP server in the App store, whether that comes by my proposal or vetting of another project is completely fine by me.

[marcelklehr]

It is my understanding that nextcloud/context_agent has extensive dependencies and apparently needs an AI provider itself to work.

This is not the case. Case closed I think? Edit: What gave you this idea?

[Simon-Spettmann]

It is my understanding that nextcloud/context_agent has extensive dependencies and apparently needs an AI provider itself to work.

This is not the case. Case closed I think? Edit: What gave you this idea?

@marcelklehr It says so in the App store, GitHub repository and documentation. And, as I mentioned, I tried to use nextcloud/context_agent without these dependencies, or at least with all dependencies except an AI provider, but couldn't get it to work. So I came to the conclusion that the documentation is correct and these are (must have) requirements.

---

This app needs Nextcloud Assistant and an AI provider to work. Read the documentation.

From https://apps.nextcloud.com/apps/context_agent

This app needs Nextcloud Assistant and an AI provider to work. Read the documentation.

From https://github.com/nextcloud/context_agent

Installation

• Make sure the Nextcloud Assistant app is installed
• Install AppAPI and setup a Deploy Demon
• Install the “Context Agent” ExApp via the “Apps” page in the Nextcloud web admin user interface
• Install a text generation backend like llm2 or integration_openai via the “Apps” page in Nextcloud

From https://docs.nextcloud.com/server/stable/admin_manual/ai/app_context_agent.html#installation

[marcelklehr]

Ah, good point then. Those docs are for using the context agent mode of assistant. For that you need assistant + text generation backend + context agent. But if you just want to use the mcp server there are no dependencies necessary. The reason you couldn't get it to work is likely a bug in the latest release: See #201

[Simon-Spettmann]

Those docs are for using the context agent mode of assistant. For that you need assistant + text generation backend + context agent. But if you just want to use the mcp server there are no dependencies necessary.

@marcelklehr That sounds great, thanks for letting me know. It would be good if the sources I quoted (especially the documentation) would reflect that as well. Otherwise people might come to the same conclusion as me. Should I create a dedicated issue for updating the docs?

The reason you couldn't get it to work is likely a bug in the latest release: See #201

Would it be okay for you if I leave it open until #201 is fixed, so that I can confirm this was indeed the cause and fix of my problem?

---

Generally speaking: Wouldn't it still be a good idea to refractor the MCP server to a dedicated exApp?

As I understand it now, this project servers two very different use cases at the same time, that being internal and external AI agent access. My (maybe naive) conclusion is that seperating these use cases would be good practice (separation of concerns) and beneficial (e.g. smaller code bases of each module). Given that you already supports adding custom services via MCP, linking both modules (back) together seems rather straight forward to me.

I’d love to hear your thoughts on this and, if you disagree, understand why.

I'm sure that I won't be the last one who comes up with this question/idea.