MCP Connector: a dedicated MCP-only ExApp, now in the App Store (OAuth 2.1, per-user)

Today we published MCP Connector to the App Store: a dedicated, MCP-only ExApp that connects your Nextcloud to AI assistants speaking the Model Context Protocol (Claude, Cursor, ChatGPT, or your own agent).

App Store: MCP Connector - Apps - App Store - Nextcloud

Source (AGPL-3.0): GitHub - street1983nk/nextcloud-mcp-connector: Curated MCP server for Nextcloud: files, calendar, notes, deck and contacts as read-first tools. Never deletes, overwrites or re-shares. · GitHub

What it is:

One click install from the store (AppAPI/ExApp, Python, built on the official MCP python-sdk). No assistant app, no AI provider, no extra dependencies: it only speaks MCP.

It is its own OAuth 2.1 authorization server following the MCP authorization spec. Hosted clients like Claude.ai and ChatGPT connect through a normal consent flow and never see a password. Admins can switch off dynamic client registration or allowlist specific clients.

Every request runs under the identity of the signed-in user. An assistant never sees more than that user sees in the web interface, and users manage and revoke their connections under Settings, Security.

Curated tool surface instead of a raw API: files (WebDAV), calendar (CalDAV), Notes, Deck, contacts (CardDAV), unified search, plus a prepare_context bundle tool. Read-first, risky writes are limited, nothing destructive.

No telemetry, no third-party calls from the connector itself. What the connected assistant reads is of course transmitted to that assistant, so choose it accordingly; the data flow is documented in the repository.

It is an early release (0.1.0) and feedback is very welcome, here or in the GitHub issues. Disclosure: I am the author.

Hi @street1983nk

Great work! Thank you for sharing it!

May I ask what the motivation was to create a separate app? I would welcome contributions to our context_agent ex app where it feels rough around the edges to consolidate and streamline efforts around MCP :folded_hands: Let’s try to wrok together to not reinvent the wheel :slight_smile:

Hi Marcel,

thank you, and fair question!

The original motivation was my own itch: I work in Claude and wanted it to see my Nextcloud files and calendar, and I was not comfortable handing an assistant an app password that could delete or re-share things. There was no way to connect a hosted assistant to Nextcloud that I would trust on my own data, so I built one.

Why a separate app rather than a contribution: the two apps point in opposite directions, and I could not find a way to express mine inside context_agent without changing what context_agent is.

context_agent lets Nextcloud’s own Assistant act inside Nextcloud: the instance brings the AI. My connector is the reverse direction: people who already live in Claude, ChatGPT or Cursor bring their own assistant, and the app gives it a curated window into their Nextcloud. That difference drove three design decisions that would not have fit naturally as contributions:

  1. It is an MCP authorization server according to the MCP spec (OAuth 2.1 with dynamic client registration, PKCE, audience-bound tokens, refresh rotation), because that is what hosted connectors like Claude.ai and ChatGPT require to sign a user in without ever seeing a password.

  2. It is non-destructive by design as its core promise: there is not a single delete, move, overwrite or re-share call in the tool set, and write tools are create-only. That is a product identity, not a permission setting, and it only works as a guarantee if the whole app is built around it.

  3. The tool set is deliberately small (20 curated tools) because external clients have hard tool limits and this server has to fit next to other MCP servers people already use.

That said, I would genuinely like to avoid reinventing wheels, and I see concrete places to work together:

  • If context_agent (or the ecosystem around it) settles on canonical tool names and schemas for common Nextcloud actions, I will gladly align mine so assistants see consistent vocabulary regardless of the direction they come from.
  • The OAuth 2.1 walk against Claude.ai and ChatGPT (including the failure modes) is documented in my repo; if any of that is useful for Nextcloud’s own MCP plans, take it or tell me where to contribute it.
  • I use a contract test that reads the live tool registry and fails when docs and registry drift apart; happy to port that pattern over if it helps.

And if AppAPI or context_agent grow first-class MCP server capabilities one day, I would much rather converge than compete. Until then I think the two apps complement each other: yours for the assistant that lives in Nextcloud, mine for the assistants that live elsewhere.

Happy to talk details any time.

Greetings from Hamburg!